{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":262374103,"defaultBranch":"master","name":"hive","ownerLogin":"2uasimojo","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2020-05-08T16:32:31.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/9142716?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1724367751.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"94b9b7b2174b8a700893acb83808ecd58270b20f","ref":"refs/heads/HIVE-2604/ProjectToDir-trunc","pushedAt":"2024-08-22T23:02:31.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Remove existing Secret files in (deprovision) Pod\n\nFor Pods with `restartPolicy: OnFailure`, a failed container may be\nrerun in the same Pod, which will reuse the same file system as the\ninitial run. When we project Secrets (for credentials, certs, etc) to\ndirectories in such containers, those writes can fail the second time\naround because the file already exists. Fix by removing the file, if it\nexists, before we write it.\n\nNote that at the time of this commit, this only affects deprovision\npods:\n- imageset pods don't use ProjectToDir\n- provision pods have `restartPolicy: Never`\n\nHIVE-2604","shortMessageHtmlLink":"Remove existing Secret files in (deprovision) Pod"}},{"before":"d171fa0c312918f1a476c65845e317eeba003a18","after":"315aa266ac11d1b32e50d7966379b7843a769704","ref":"refs/heads/HIVE-2320/machinepool-machine-labels","pushedAt":"2024-08-22T18:48:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"MachinePool API: MachineLabels\n\nThe existing MachinePool.Spec.Labels field populates the resulting\nMachineSets' *MachineSpec*, resulting in the specified labels ending up\non *Nodes*.\n\nThis commit adds MachinePool.Spec.MachineLabels, which populates the\n*MachineTemplateSpec*, resulting in the specified labels ending up on\n*Machines*. But note that we will ignore labels that conflict with those\ngenerated by installer code:\n- machine.openshift.io/cluster-api-cluster\n- machine.openshift.io/cluster-api-machineset\n\nWe also add MachinePool.Status.OwnedMachineLabels, corresponding to the\nexisting OwnedLabels, to help us merge values correctly.\n\nHIVE-2320","shortMessageHtmlLink":"MachinePool API: MachineLabels"}},{"before":"28c283d48d7a4f6fb4ceb2bdd91e2ca81fe55f0f","after":"24cf59f548bdd5d1f675609047b0af57e788412f","ref":"refs/heads/azidentity-mce-2.5","pushedAt":"2024-08-21T22:45:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"DNM: debug printf for azure ProjectToDir\n\n...to try to narrow down why we see this error:\n\n```\nFailed to write file\" error=\"open /.azure/osServicePrincipal.json: permission denied\n```\n\n...on *deprovision*, but not on *provision*, which uses exactly the same\ncode to set up that file!","shortMessageHtmlLink":"DNM: debug printf for azure ProjectToDir"}},{"before":"9615c77cd786dd82079a9dacd60b64c882f56327","after":null,"ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-21T19:53:02.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"}},{"before":"a7f30651d2c3eca95a5cb0f2d866ac8aa5b11bff","after":"28c283d48d7a4f6fb4ceb2bdd91e2ca81fe55f0f","ref":"refs/heads/azidentity-mce-2.5","pushedAt":"2024-08-20T22:22:23.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Bump azidentity\n\nhttps://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMAZUREAZURESDKFORGOSDKAZIDENTITY-7246767\n\nManual cherry-pick of #2319 / #2308.\n\nHIVE-2532","shortMessageHtmlLink":"Bump azidentity"}},{"before":"fcb6d7511604090894e391bc339d28d17a609ea0","after":"a7f30651d2c3eca95a5cb0f2d866ac8aa5b11bff","ref":"refs/heads/azidentity-mce-2.5","pushedAt":"2024-08-20T22:19:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"DNM: debug osServicePrincipal EPERM via printf","shortMessageHtmlLink":"DNM: debug osServicePrincipal EPERM via printf"}},{"before":"305d73ba9c56540ea38a3770bcd8bdbfce64421a","after":"d171fa0c312918f1a476c65845e317eeba003a18","ref":"refs/heads/HIVE-2320/machinepool-machine-labels","pushedAt":"2024-08-20T21:50:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"MachinePool API: MachineLabels\n\nThe existing MachinePool.Spec.Labels field populates the resulting\nMachineSets' *MachineSpec*, resulting in the specified labels ending up\non *Nodes*.\n\nThis commit adds MachinePool.Spec.MachineLabels, which populates the\n*MachineTemplateSpec*, resulting in the specified labels ending up on\n*Machines*.\n\nWe also add MachinePool.Status.OwnedMachineLabels, corresponding to the\nexisting OwnedLabels, to help us merge values correctly.\n\nHIVE-2320","shortMessageHtmlLink":"MachinePool API: MachineLabels"}},{"before":"536482d9794ea57a6e8e25ac36b58ac7a06779a6","after":null,"ref":"refs/heads/e2e-statefulset-logs","pushedAt":"2024-08-20T21:43:56.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"}},{"before":"953397386ce12469832bf267f4f6168820a17e4e","after":"61ce64fcfb648637f4b1a4ce7d4d982a0cf6fa4e","ref":"refs/heads/HIVE-2582/azure-mp-network","pushedAt":"2024-08-20T21:21:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Azure MachinePool: NetworkResourceGroupName, ComputSubnet, VirtualNetwork\n\nAdd networking fields to the Azure MachinePool API:\n\nMachinePool.Spec.Platform.Azure.NetworkResourceGroupName will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.NetworkResourceGroupName...\nunless VirtualNetwork is unspecified, in which case the ResourceGroup is\nused. (This logic lives in the upstream installer code and is accurate\nat the time of this writing :innocent:)\n\nMachinePool.Spec.Platform.Azure.ComputeSubnet will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.Subnet.\n\nMachinePool.Spec.Platform.Azure.VirtualNetwork will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.Vnet.\n\nThe MachinePool API field names are taken from their install-config.yaml\nequivalents.\n\nHIVE-2582","shortMessageHtmlLink":"Azure MachinePool: NetworkResourceGroupName, ComputSubnet, VirtualNet…"}},{"before":"fa11da6208e6e2db4cd9827c929ddc55de4eab6a","after":"953397386ce12469832bf267f4f6168820a17e4e","ref":"refs/heads/HIVE-2582/azure-mp-network","pushedAt":"2024-08-20T21:16:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Azure MachinePool: NetworkResourceGroupName, ComputSubnet, VirtualNetwork\n\nAdd networking fields to the Azure MachinePool API:\n\nMachinePool.Spec.Platform.Azure.NetworkResourceGroupName will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.NetworkResourceGroupName...\nunless VirtualNetwork is unspecified, in which case the ResourceGroup is\nused. (This logic lives in the upstream installer code and is accurate\nat the time of this writing :innocent:)\n\nMachinePool.Spec.Platform.Azure.ComputeSubnet will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.Subnet.\n\nMachinePool.Spec.Platform.Azure.VirtualNetwork will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.Vnet.\n\nThe MachinePool API field names are taken from their install-config.yaml\nequivalents.\n\nHIVE-2582","shortMessageHtmlLink":"Azure MachinePool: NetworkResourceGroupName, ComputSubnet, VirtualNet…"}},{"before":"0b2397930a2a3fe90a58bb76fa7427c381f85c2e","after":"fa11da6208e6e2db4cd9827c929ddc55de4eab6a","ref":"refs/heads/HIVE-2582/azure-mp-network","pushedAt":"2024-08-20T20:58:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Azure MachinePool: ComputSubnet, VirtualNetwork\n\nAdd networking fields to the Azure MachinePool API:\n\nMachinePool.Spec.Platform.Azure.ComputeSubnet will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.Subnet.\n\nMachinePool.Spec.Platform.Azure.VirtualNetwork will end up in\nMachineSet.Spec.Template.Spec.ProviderSpec.Value.Vnet.\n\nThe MachinePool API field names are taken from their install-config.yaml\nequivalents.\n\nHIVE-2582","shortMessageHtmlLink":"Azure MachinePool: ComputSubnet, VirtualNetwork"}},{"before":null,"after":"536482d9794ea57a6e8e25ac36b58ac7a06779a6","ref":"refs/heads/e2e-statefulset-logs","pushedAt":"2024-08-20T17:52:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"e2e: Capture logs from statefulsets (clustersync, machinepool)\n\nIn our e2e, we've been missing capturing logs from the controllers that\nhave been sharded out into statefulsets: clustersync and (recently, via\nHIVE-2537) machinepool. Fix.","shortMessageHtmlLink":"e2e: Capture logs from statefulsets (clustersync, machinepool)"}},{"before":"ef18c9ba2a729771bc42046b755e197e75f0638c","after":null,"ref":"refs/heads/HIVE-2536/machinepool-poll-sharded","pushedAt":"2024-08-20T17:39:02.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"}},{"before":null,"after":"ef18c9ba2a729771bc42046b755e197e75f0638c","ref":"refs/heads/HIVE-2536/machinepool-poll-sharded","pushedAt":"2024-08-18T19:48:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Fix MachinePool poll interval for sharded controller\n\nPrevious work (#2310 / 4117577) added a knob to control the poll\ninterval for the MachinePool controller.\n\nThen a subsequent effort (#2341 / 35ce9c6) split the MachinePool\ncontroller into its own StatefulSet.\n\nBut the latter forgot to carry the poll interval plumbing into the\nsharded version of the controller.\n\nFix.\n\nHIVE-2536","shortMessageHtmlLink":"Fix MachinePool poll interval for sharded controller"}},{"before":"3d12159c3daf4cf8ea57fd53db88d09f443a7f65","after":"305d73ba9c56540ea38a3770bcd8bdbfce64421a","ref":"refs/heads/HIVE-2320/machinepool-machine-labels","pushedAt":"2024-08-18T17:06:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"MachinePool API: MachineLabels\n\nThe existing MachinePool.Spec.Labels field populates the resulting\nMachineSets' *MachineSpec*, resulting in the specified labels ending up\non *Nodes*.\n\nThis commit adds MachinePool.Spec.MachineLabels, which populates the\n*MachineTemplateSpec*, resulting in the specified labels ending up on\n*Machines*.\n\nWe also add MachinePool.Status.OwnedMachineLabels, corresponding to the\nexisting OwnedLabels, to help us merge values correctly.\n\nHIVE-2320","shortMessageHtmlLink":"MachinePool API: MachineLabels"}},{"before":"3a3c810cc9147a20f1f6af5998802b21538a7894","after":"9615c77cd786dd82079a9dacd60b64c882f56327","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-18T15:05:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager with a `hive` prefix:\n- For many paths, the prefix will be `hiveN` where `N` is an integer\n  unique to the code path that's configuring the fieldManager. We\n  did this to make it easier to trace these paths in the code (which can\n  otherwise be Very Hard™).\n- `hiveutil` commands will show up as either `hiveutil-$subcommand` or\n  `hiveN-util-$subcommand`, depending which path they go through to\n  create their client.\n\nIf you find cases that still show up as `manager` -- or some other\nunhelpful string -- please open a bug!\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":null,"after":"3d12159c3daf4cf8ea57fd53db88d09f443a7f65","ref":"refs/heads/HIVE-2320/machinepool-machine-labels","pushedAt":"2024-08-16T22:55:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"MachinePool API: MachineLabels\n\nThe existing MachinePool.Spec.Labels field populates the resulting\nMachineSets' *MachineSpec*, resulting in the specified labels ending up\non *Nodes*.\n\nThis commit adds MachinePool.Spec.MachineLabels, which populates the\n*MachineTemplateSpec*, resulting in the specified labels ending up on\n*Machines*.\n\nWe also add MachinePool.Status.OwnedMachineLabels, corresponding to the\nexisting OwnedLabels, to help us merge values correctly.\n\nHIVE-2320","shortMessageHtmlLink":"MachinePool API: MachineLabels"}},{"before":"3ed7f69cec6797f12d4b872c1c448f434699374e","after":null,"ref":"refs/heads/HIVE-2585/clustersync-backoff","pushedAt":"2024-08-16T21:32:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"}},{"before":null,"after":"3ed7f69cec6797f12d4b872c1c448f434699374e","ref":"refs/heads/HIVE-2585/clustersync-backoff","pushedAt":"2024-08-16T21:32:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"DNM: Error clustersync controller for backoff\n\nWithout this commit, the clustersync controller returns\n`reconcile.Result{Requeue: true, RequeueAfter: 0}, nil` when it fails to\napply any syncset resource. I.e. \"This is not an error, but requeue this\nrequest immediately\". Per the referenced card, and from activity seen in\nSD aka HCM when a syntax error was causing a large number of syncset\nfailures, we suspected that this was _actually_ requeueing such requests\nimmediately, resulting in thrashing. This commit was conceived to return\na non-nil error in these cases, on the theory that this would cause the\nrate limiter to kick in and back off the requests exponentially.\n\nHowever, it was discovered that the rate limiter is doing its thang\nanyway. So we don't need to do anything here.\n\nHIVE-2585","shortMessageHtmlLink":"DNM: Error clustersync controller for backoff"}},{"before":"39e2533d9b99c19a5772b38fd57959932a816c18","after":null,"ref":"refs/heads/HIVE-2598/doc-clusterpool-troubleshooting","pushedAt":"2024-08-16T16:09:22.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"}},{"before":"e39b6162e182195da674820b762353f7024bc277","after":null,"ref":"refs/heads/HIVE-2597/label-clusterpool-cds","pushedAt":"2024-08-15T21:59:14.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"}},{"before":null,"after":"39e2533d9b99c19a5772b38fd57959932a816c18","ref":"refs/heads/HIVE-2598/doc-clusterpool-troubleshooting","pushedAt":"2024-08-15T21:22:35.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"Document ClusterPool troubleshooting\n\nHIVE-2598","shortMessageHtmlLink":"Document ClusterPool troubleshooting"}},{"before":null,"after":"e39b6162e182195da674820b762353f7024bc277","ref":"refs/heads/HIVE-2597/label-clusterpool-cds","pushedAt":"2024-08-15T19:46:52.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"ClusterPool: Label owned ClusterDeployments\n\nSince ClusterPools create their ClusterDeployments in unique namespaces,\nit could be tricky to find them -- you would have to do some variant of\n`oc get cd -A | grep $clusterpoolName` or some fancy jq'ing.\n\nWith this commit, we add two labels to ClusterDeployments created by a\nClusterPool:\n- `hive.openshift.io/clusterpool-namespace`\n- `hive.openshift.io/clusterpool-name`\n\n...with the obvious values. With this, you should be able to find all\nCDs for a pool unambiguously with a query like:\n\n`oc get cd -A -l hive.openshift.io/clusterpool-namespace=poolns,hive.openshift.io/clusterpool-name=poolname`\n\nOften you'll only have one pool in a namespace, or your pool name will\nbe unique in your cluster, so you'll be able to get away with just one\nof those filters.\n\nNote that upgrading your hive to/past this commit will not automatically\nlabel existing ClusterPool-owned ClusterDeployments. If this is crucial:\n- Scale your pool down to zero\n- Delete all existing ClusterClaims\n- Scale your pool back to the desired size\n\n...or manually label them :)\n\nHIVE-2597","shortMessageHtmlLink":"ClusterPool: Label owned ClusterDeployments"}},{"before":"e75f37ecd656990a8d43deea32d81b3be1dcf895","after":"3a3c810cc9147a20f1f6af5998802b21538a7894","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-15T18:44:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager with a `hive` prefix:\n- For many paths, the prefix will be `hiveN` where `N` is an integer\n  unique to the code path that's configuring the fieldManager. We\n  did this to make it easier to trace these paths in the code (which can\n  otherwise be Very Hard™).\n- `hiveutil` commands will show up as either `hiveutil-$subcommand` or\n  `hiveN-util-$subcommand`, depending which path they go through to\n  create their client.\n\nIf you find cases that still show up as `manager` -- or some other\nunhelpful string -- please open a bug!\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":"5cf9d4fb7761a1ce839e8dcbf69d7c18e6355b99","after":"e75f37ecd656990a8d43deea32d81b3be1dcf895","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-14T21:05:50.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager with a `hive` prefix:\n- For many paths, the prefix will be `hiveN` where `N` is an integer\n  unique to the code path that's configuring the fieldManager. We\n  did this to make it easier to trace these paths in the code (which can\n  otherwise be Very Hard™).\n- `hiveutil` commands will show up as either `hiveutil-$subcommand` or\n  `hiveN-util-$subcommand`, depending which path they go through to\n  create their client.\n- Some cases still show up as `manager` because the public APIs used by\n  those code paths to not provide access to the `FieldManager` option.\n  One example is here [1] where the `PatchOptions` object is explicitly\n  coded but doesn't populate `FieldManager` (which it could get from the\n  `ApplyOptions` receiver [2]). Similarly here [3] `PatchOptions` is\n  hardcoded to `nil`. This (or something like it??) is affecting\n  [Selector]SyncSet `patch`es.\n\n[1] https://github.com/openshift/hive/blob/e6ca1ac7e969b076dd7e287417b44794fe6c81ee/vendor/k8s.io/kubectl/pkg/cmd/apply/apply.go#L577\n[2] https://github.com/openshift/hive/blob/e6ca1ac7e969b076dd7e287417b44794fe6c81ee/vendor/k8s.io/kubectl/pkg/cmd/apply/apply.go#L91\n[3] https://github.com/openshift/hive/blob/e6ca1ac7e969b076dd7e287417b44794fe6c81ee/vendor/k8s.io/kubectl/pkg/cmd/apply/apply.go#L913\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":"e6ca1ac7e969b076dd7e287417b44794fe6c81ee","after":"5cf9d4fb7761a1ce839e8dcbf69d7c18e6355b99","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-14T21:03:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager with a `hive` prefix:\n- For many paths, the prefix will be `hiveN` where `N` is an integer\n  unique to the code path that's configuring the fieldManager. We\n  did this to make it easier to trace these paths in the code (which can\n  otherwise be Very Hard™).\n- `hiveutil` commands will show up as either `hiveutil-$subcommand` or\n  `hiveN-util-$subcommand`, depending which path they go through to\n  create their client.\n- Some cases still show up as `manager` because the public APIs used by\n  those code paths to not provide access to the `FieldManager` option.\n  One example is here [1] where the `PatchOptions` object is explicitly\n  coded but doesn't populate `FieldManager` (which it could get from the\n  `ApplyOptions` receiver [2]). Similarly here [3] `PatchOptions` is\n  hardcoded to `nil`. This (or something like it??) is affecting\n  [Selector]SyncSet `patch`es.\n\n[1] https://github.com/openshift/hive/blob/e6ca1ac7e969b076dd7e287417b44794fe6c81ee/vendor/k8s.io/kubectl/pkg/cmd/apply/apply.go#L577\n[2] https://github.com/openshift/hive/blob/e6ca1ac7e969b076dd7e287417b44794fe6c81ee/vendor/k8s.io/kubectl/pkg/cmd/apply/apply.go#L91\n[3] https://github.com/openshift/hive/blob/e6ca1ac7e969b076dd7e287417b44794fe6c81ee/vendor/k8s.io/kubectl/pkg/cmd/apply/apply.go#L913\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":"3b4c659efbc94aebe0e032443ef896a44115b79a","after":"e6ca1ac7e969b076dd7e287417b44794fe6c81ee","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-14T18:33:45.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager named \"hive-$controllername\".\n\nNOTE: Keep an eye out for Apply updates on a spoke that are still tagged\n`manager`. There's one path that refused to be fixed.\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":"865b43e839cd1063a2b09d1e699ff6b6f30b1ccd","after":"3b4c659efbc94aebe0e032443ef896a44115b79a","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-14T15:02:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager named \"hive-$controllername\".\n\nNOTE: Keep an eye out for Apply updates on a spoke that are still tagged\n`manager`. There's one path that refused to be fixed.\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":"720aa152bbb26626d344644ca3958f1e8770b857","after":"865b43e839cd1063a2b09d1e699ff6b6f30b1ccd","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-13T22:36:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager named \"hive-$controllername\".\n\nNOTE: Keep an eye out for Apply updates on a spoke that are still tagged\n`manager`. There's one path that refused to be fixed.\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}},{"before":"2b0842bddbe74cb393e5016c6ec5bfc5b419a30d","after":"720aa152bbb26626d344644ca3958f1e8770b857","ref":"refs/heads/HIVE-1744/userAgent","pushedAt":"2024-08-13T21:45:15.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"2uasimojo","name":"Eric Fried","path":"/2uasimojo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9142716?s=80&v=4"},"commit":{"message":"fieldManager: \"hive-$controllername\"\n\nWhen debugging CR updates, e.g. via `--show-managed-fields`, hive used\nto annoyingly show `manager: manager`, which is not helpful.\n\nWith this commit, we've tried to make sure all updates are driven by a\nfieldManager named \"hive-$controllername\".\n\nHIVE-1744","shortMessageHtmlLink":"fieldManager: \"hive-$controllername\""}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEoctMlAA","startCursor":null,"endCursor":null}},"title":"Activity · 2uasimojo/hive"}