text:
v1beta1 KfDef

Bootstrapping KfDef for v1beta1.
Relates to kubeflow/kubeflow#4002

This change is

Thanks
LGTM
@yanniszark @kkasravi comments?

please help and take a look at condition types and reasons, I try to fit the new status into our new semantics.

Will it be compatible with https://github.com/kubeflow/kubeflow/blob/v0.6-branch/bootstrap/config/kfctl_gcp_iap.0.6.2.yaml ?

no, this is the new version.  we will make kfctl to be backward compatible with v1alpha1 KfDef, tho.

there is a merged doc on conditions and ApplicationStatusCondition

@kkasravi I've updated the conditions part according to the link, could you take a second pass?

thanks @gabrielwen
/lgtm

@yanniszark will wait for your review.  please approve this when you think it looks good.

@yanniszark @kkasravi Can you please take another look?
@gabrielwen What are the remaining issues to be resolved? It looks like we are waiting on @kkasravi to answer the question about why value is StringOrArray?
@yanniszark @kkasravi Can you please prioritize reviewing this? Its critical we get the v1beta1 API finalized so we can get the implementation done in time for 0.7.

Great discussion !
I've nothing to add to the comments.
Just a small question, is there a doc or issue tracking the steps to be done make kfctl backwards compatible?

Great discussion !
I've nothing to add to the comments.
Just a small question, is there a doc or issue tracking the steps to be done make kfctl backwards compatible?

kubeflow/kubeflow#4002 is the tracking issue but it doesn't really have the steps to make it compatible.  After this PR we need another one to unify both paths (v1alpha1/v1beta1)

@yanniszark @kkasravi Can you please take another look?
@gabrielwen What are the remaining issues to be resolved? It looks like we are waiting on @kkasravi to answer the question about why value is StringOrArray?
@yanniszark @kkasravi Can you please prioritize reviewing this? Its critical we get the v1beta1 API finalized so we can get the implementation done in time for 0.7.

yes, I think that is the only question.

@swiftdiaries I think to make kfctl backwards compatible we just need to write a conversion function to convert v1alpha1 specs to v1beta1 specs; and then we can just run that when kfctl runs.

@kkasravi to answer the question about why value is StringOrArray?

there are use cases where an array would be valuable.
If we allow lists to be passed to kf apps then params.env is not the best way to pass a list.
This approach (string or array-of-string) is used by tektoncd in their parameter passing implementation. We should try and have well typed information for app params

Would it make sense to change Plugin to include data where this info can be
embedded?

@kkasravi the Spec of a plugin is already free-form data.
The author of a Plugin can freely choose the correct structure that fits their plugin, including the structure you mentioned.
Why would we force a certain structure upon all plugins beforehand?

there are use cases where an array would be valuable.
If we allow lists to be passed to kf apps then params.env is not the best way to pass a list.

Has such a use-case come up though? Is there a Kubeflow application that needs a list?
I'm hesitant about this because if we start conservatively then AFAIK we can make it StringOrArray without breaking backwards compatibility.
However, if we make it StringOrArray from the start, then we won't be able to take it back without breaking compatibility.
The last outstanding issue is Object vs RawExtension (https://github.com/kubeflow/kfctl/pull/29#discussion_r323288805).

Responding to @kkasravi's question about how users would modify the DM templates. I think this is working as intended. If there are specific parameters we want to expose (e.g. workloadIdentity, pipelinepersistentstorage) the plugin owners can define an appropriate high level API.
I don't think we need to let users embed arbitrary json/YAML.
The underlying config files are DM config files. If users want to easily modify those and customize them in weird ways they can do that by copying that to an appropriate directory, modifying them, and running gcloud to create the GCP infra. They can  then just use kfctl to install Kubeflow on their existing cluster.

but could we do more in this area? My point is we already create an opinionated cluster:
2 machines with 8 vCPUs and 30 GB of memory, tpu's disabled, 0 gpus.
Just as we're providing device overlays that can be configured so that jobs run on accelerated hardware, can we provide hooks that vendors could utilize to meet customer requirements?

/hold
place hold until runtime.Object/runtime.RawExtension is resolved.

/hold cancel

@yanniszark @kkasravi could I have lgtm from both of you?

/lgtm

/lgtm
/approve
/hold
To give @yanniszark time to review

@yanniszark done, could you take a final look? :)

@gabrielwen thanks for all the great work.
/lgtm
One last concern I had, which is worth mentioning now:
AFAIK, we don't have a good story for providing secrets for securing applications.
eg we probably want to configure MySQL, OIDC clients, Minio etc with good random passwords and not default ones like we do now.
Are we confident that we'll be able to have a good story for this without needing a new version?
/cc @jlewi
@gabrielwen @jlewi that's all from my side, please remove the hold when you believe everything is ready.

@yanniszark We can extend SecretSource if need be to allow people alternative methods of referencing secrets.

/lgtm
/approve
/hold cancel

authors: gabrielwen jlewi kkasravi kunmingg swiftdiaries yanniszark

repo: kubeflow/kfctl


text:
Running the tf-flower sample kfp returns 404 on the first step of the run.

/kind question
What steps did you take and what happened:
Created a jupyter notebook and ran the following example. https://github.com/kubeflow/kfserving/tree/master/docs/samples/pipelines
On the first step I'm getting 404 for the inference service.
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"inferenceservices.serving.kubeflow.org "tf-sample" not found","reason":"NotFound","details":{"name":"tf-sample","group":"serving.kubeflow.org","kind":"inferenceservices"},"code":404}
What did you expect to happen:
Get 200.
Anything else you would like to add:
I'm running in my user namespace. This is my code:
kfserving_op = components.load_component_from_url('https://raw.githubusercontent.com/kubeflow/pipelines/master/components/kubeflow/kfserving/component.yaml')

@dsl.pipeline(
  name='kfserving pipeline',
  description='A pipeline for kfserving.'
)
def kfservingPipeline(
    action = 'update',
    model_name='tf-sample',
    default_model_uri='gs://kfserving-samples/models/tensorflow/flowers',
    canary_model_uri='gs://kfserving-samples/models/tensorflow/flowers-2',
    canary_model_traffic_percentage='10',
    namespace='ghosn-patrick',
    framework='tensorflow',
    default_custom_model_spec='{}',
    canary_custom_model_spec='{}',
    autoscaling_target='0',
    kfserving_endpoint=''
):

    # define workflow
    kfserving = kfserving_op(action = action,
                             model_name=model_name,
                             default_model_uri=default_model_uri,
                             canary_model_uri=canary_model_uri,
                             canary_model_traffic_percentage=canary_model_traffic_percentage,
                             namespace='ghosn-patrick',
                             framework=framework,
                             default_custom_model_spec=default_custom_model_spec,
                             canary_custom_model_spec=canary_custom_model_spec,
                             autoscaling_target=autoscaling_target,
                             kfserving_endpoint=kfserving_endpoint).set_image_pull_policy('Always')

# Compile pipeline
import kfp.compiler as compiler
compiler.Compiler().compile(kfservingPipeline, 'tf-flower.tar.gz')

# Execute pipeline
run = client.run_pipeline(experiment.id, 'tf-flower', 'tf-flower.tar.gz')

Seems I needed to create the inferring service first.

Seems I needed to create the inferring service first.

source: gharchive/issue

repo: kubeflow/kfserving

license_type: permissive

license_source: github-api


text:
Switch the KFServing build to Kubeflow build being based on Tekton+Kaniko

Follow the conversation here
https://github.com/kubeflow/kfserving/pull/319
/assign @jinchihe
cc @ellis-bigelow @kkasravi

thanks @animeshsingh
does kfserving do something similar as some of the other kubeflow repos (kubeflow, kfctl, manifests) which involves prow, presubmit, postsubmit, periodic?

@kkasravi ye it's prow with presubmit, there is no postsubmit and periodic setup.

@yuzisun thanks
the current kfctl Pipeline isn't parameterized under kustomize to the extent that any Github source and Image can be plugged in, but i'll take a look at kfserving's prow presubmit to see if it would be possible

@animeshsingh @kkasravi I'm glad to do that, thanks!

@jinchihe any movement along these lines?

@animeshsingh not yet due to higher priority things, but will start very soon.

authors: animeshsingh jinchihe kkasravi yuzisun


text:
Notebooks 2.0 // Frontend // Workspaces table // Workspace redirect status column

Insert a column in the beggining of the workspaces table (first column), containing an icon representing the redirect status for that workspace. The information will come from these fields, and should be fetched from the backend service. The icon comes from the "level" field, and the "text" should be displayed when the mouse hovers the icon.

/assign

authors: asaadbalum paulovmr

repo: kubeflow/notebooks


text:
update OWNERS

Add mitake as a reviewer
Remove zjj2wry (based on a request from jlewi)

/cc @jlewi @gaocegege this is what we talked in slack, could you check it?

This change is

Coverage remained the same at 45.236% when pulling 942ee8addefe17a5ff3dbc780bb15ba33626561a on mitake:owners into be41326985e15663aa04f92ddd2b34e5e34ef178 on kubeflow:master.

/lgtm
/approve

source: gharchive/pull-request

authors: coveralls jlewi mitake

repo: kubeflow/tf-operator


text:
Support ARM64 platform in PyTorch examples

Currently, we support only the AMD64 platform in all PyTorch examples.
However, some users use ARM64 machines such as Macbooks. So, supporting the ARM64 platform allows users to try the training-operator examples on their machines easily.
Contributors should support the following examples by adding the platform parameters here: https://github.com/kubeflow/training-operator/blob/e31d11faa9f6ce5111b60c01079d39295589e0ef/.github/workflows/publish-example-images.yaml#L24

[ ] examples/pytorch/cpu-demo/Dockerfile
[ ] examples/pytorch/elastic/imagenet/Dockerfile
[ ] examples/pytorch/elastic/echo/Dockerfile
[ ] examples/pytorch/mnist/Dockerfile
[ ] examples/pytorch/mnist/Dockerfile-mpi
[ ] examples/pytorch/smoke-dist/Dockerfile

/good-first-issue

Hey! Interested in this project, could I be assigned to this issue?

Hey! Interested in this project, could I be assigned to this issue?

Sure, feel free to assign yourself with /assign comment.

/assign

repo: kubeflow/training-operator


text:
close the "kubeflow docs restructure" kanban

There is still a legacy project from the 1.3 release on this repo.
We should close this in preference of the new one (on the kubeflow organisation, rather than this repo).
I have also create an issue https://github.com/kubeflow/website/issues/2805 (which should be pinned) to help users find the new Kanban.

/priority p3

@RFMVasconcelos are you OK if we close the old Kanban?

@thesuperzapper thank you for organizing the new kanban! 🚀
I have just confirmed that there are no lost items, and hence closed the previous kanban.

authors: RFMVasconcelos thesuperzapper

repo: kubeflow/website


text:
Create a Fairing section for the documentation

fixes #590

This change is

Preview https://deploy-preview-599--competent-brattain-de2d6d.netlify.com/docs/fairing/

Thanks @abhi-g! I think we should hold off on adding the section until we have some content to include. Readers may be surprised and even frustrated to find no content, especially as there's no indication of what Fairing is.
FYI I have a meeting later today with @joeliedtke to discuss the Fairing docs. He's the tech writer working with the Fairing team.
I'll apply a hold, to stop this PR from being merged without direct intention. Please do cancel the hold if you disagree. :)
/hold

Sounds reasonable. I created a bunch of issues in the website repo to add
various documentation for Fairing.
On Thu, Apr 4, 2019 at 9:26 PM Sarah Maddox notifications@github.com
wrote:

Thanks @abhi-g https://github.com/abhi-g! I think we should hold off on
adding the section until we have some content to include. Readers may be
surprised and even frustrated to find no content, especially as there's no
indication of what Fairing is.
FYI I have a meeting later today with @joeliedtke
https://github.com/joeliedtke to discuss the Fairing docs. He's the
tech writer working with the Fairing team.
I'll apply a hold, to stop this PR from being merged without direct
intention. Please do cancel the hold if you disagree. :)
/hold
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/pull/599#issuecomment-480144022, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALOqZrC2gUoziUIjxpaQwgttqvIMKpD_ks5vdtBcgaJpZM4cdwdz
.

We now have a candidate page that will appear in this section. See PR https://github.com/kubeflow/website/pull/603
I'll LGTM this PR and remove the hold, so that you can approve and merge as soon as the above PR is approved. :)

/hold cancel
/lgtm

Thanks.
On Fri, Apr 5, 2019 at 8:50 PM Sarah Maddox notifications@github.com
wrote:

/hold cancel
/lgtm
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/pull/599#issuecomment-480471485, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALOqZhGm1xSQCvVQKZ0JXb-3KsEAngimks5veBl-gaJpZM4cdwdz
.

/hold cancel
/approve

authors: abhi-g sarahmaddox


text:
Add --from-url for function deployment

Is this a BUG REPORT or FEATURE REQUEST?:
FEATURE REQUEST
What you expected to happen:
Would be possible for kubeless function deploy to recognize the a script's github link, maybe add --from-url for that command?

It should be possible to add the support for --from-url for kubeless function deploy. A PR would be welcomed :)

This is now available. Note that instead of having a different flag it is possible to specify an URL to the flag --from-file

authors: andresmgot hwa123 murali-reddy

repo: kubeless/kubeless

license_source: bigquery


text:
Fix openstack upload when daily images are available 1

Change content and motivation
Fix image upload on OpenStack so it doesnt' check md5sum of an already uploaded image. This way daily build images with new md5sum:s doesn't trigger a new file upload to OpenStack.

Now I also included fix for failing Azure. The problem was a missing subdomain parameter in the config-template for Azure.

I merged it since I think there were problems with openstack if a new user were trying with master.

Forgot to merge before close:-)

Looks good!

authors: andersla mcapuccini

repo: kubenow/KubeNow


text:
add kube-ovn-controller nodeAffinity prefer not on ic gateway

Pull Request

[ ] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Features
Bug fixes
Docs
Tests

Which issue(s) this PR fixes
Fixes #(issue-number)
WHAT

🤖 Generated by Copilot at a09dea1
Add node affinity rule to controller deployment in various files. This rule prevents the controller pod from running on inter-cluster gateway nodes, which are labeled with ovn.kubernetes.io/ic-gw.

🤖 Generated by Copilot at a09dea1

Controller pod shuns
ic-gw nodes in OVN
Autumn leaves falling

HOW

🤖 Generated by Copilot at a09dea1

Add node affinity rule to controller deployment to prefer nodes without ovn.kubernetes.io/ic-gw label (link, link, link, link)

Why prefer not on ic gateway?

Why prefer not on ic gateway?

If there is only one kube-ovn-controller pod ,  and it is on the ic gateway ,
when the gateway is down, kube-ovn-controller will take time to recover on the other node,  the start_ic command
cmd := exec.Command("/usr/share/ovn/scripts/ovn-ctl",
	fmt.Sprintf("--ovn-ic-nb-db=%s", genHostAddress(icHost, icNbPort)),
	fmt.Sprintf("--ovn-ic-sb-db=%s", genHostAddress(icHost, icSbPort)),
	fmt.Sprintf("--ovn-northd-nb-db=%s", c.config.OvnNbAddr),
	fmt.Sprintf("--ovn-northd-sb-db=%s", c.config.OvnSbAddr),
	"start_ic")

is executed by kube-ovn-controller, so it may take several minutes time for the ovn-ic to recover.

authors: changluyi oilbeater

repo: kubeovn/kube-ovn


text:
Fix local helm releases deletion issue

What this PR does / why we need it:
releasesFilterFn is used to filter out the helm releases that will be uninstalled. When using local helm charts, the helm releases can be deleted without any releases after applying kubeone apply again because we are comparing the Chart Name with the path of the Chart (HelmRelease.Chart is considered a chart path for local usage).
This PR will allow kubeone to correctly read the chart name for local and remote helm charts!
Which issue(s) this PR fixes:

Fixes #3211
What type of PR is this?

Special notes for your reviewer:
Does this PR introduce a user-facing change? Then add your Release Note here:

NONE

Documentation:

NONE

/assign
/cc @xmudrii @kron4eg

/approve
/lgtm

repo: kubermatic/kubeone


text:
Fix azure storage example

Seems like this commit https://github.com/kubernetes-helm/chartmuseum/commit/57542af46f66c7f861b0a8a3353a8ce9bad7b9b0  didn't catch all the references

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.
After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

User @mads-hartmann isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

I have signed the CLA now

@mads-hartmann thanks for catching that!

@jdolitsky You're welcome :)

repo: kubernetes-helm/chartmuseum


text:
pkg/findprocess: Add a new package for portable process detection

And use the new package for portable process-existence checks in the oci package, addressing that part of #1407's portability goals.
The traditional POSIX approach to detecting processes is to kill(pid, 0) them and check for ESRCH.  However, Go's os.Process makes detecting that a bit awkward.
On Unix, Go's os.FindProcess implementation always succeeds.  And os.Process's Signal translates ESRCH to an internal errFinished.  The Unix wrapper here rolls the FindProcess and Signal(0) calls together, and translates os's errFinished to a public ESRCH.
On Windows, os.Process's Signal only supports kills, so we can't perform a check like POSIX's kill(pid, 0).  Instead, this commit assumes os.FindProcess will return errors on nonexistent processes, although that behavior is not covered in the Go docs.  The Windows os.FindProcess wraps an OpenProcess call.  OpenProcess can set a few errors, including ERROR_INVALID_PARAMETER and ERROR_ACCESS_DENIED.  It's possible there's an ESRCH analog in their system error codes, but I'm not going to dig through and find it ;).  Once someone can test this on a Windows machine, they can tell us what error(s) to look for.
Another possible portability issue is the use of sleep in the tests.  That's fine for POSIX systems, but we may need to slot in another command for Windows.

The integration tests are happy here, so I think it's good to go.  CC @vbatts.

/test all

@mrunalp @runcom @vbatts @umohnani8 PTAL
Passes all tests.

/ok-to-test

It seems https://github.com/kubernetes-incubator/cri-o/pull/1407 is failing on what this PR fixes.
I can rebase once this merged.

LGTM

@runcom PTAL

All Green. Merging.

authors: mrunalp rhatdan vbatts wking

repo: kubernetes-incubator/cri-o


text:
Handle container creation failures gracefully

Under very heavy load, VM based containers can take more than 10s to start VMs, triggering the CRI-O container creation timeout. To gracefully handling that situation this PR:

Increases the container creation timeout
Asks the runtime for container deletion when creation fails.

/ok-to-test

LGTM

/test all

LGTM but tests seem out

can you rebase please?

If you rebase this, the tests should now work.

/retest

/test all

@runcom @mrunalp I think the single e2e failure is also expected.

/test e2e_rhel

Tests are now passing, merging.

authors: mrunalp rhatdan runcom sameo


text:
DigitalOcean with DO_TOKEN set correctly throws fatal error "invalid configuration: no configuration has been provided"

Here is the Terraform source for the external DNS part of my project:
resource "kubernetes_service_account" "external_dns" {
  metadata {
    name = "external-dns"
  }
}

resource "kubernetes_cluster_role" "external_dns" {
  metadata {
    name = "external-dns"
  }

  rule {
    api_groups = [""]
    resources  = ["services"]
    verbs      = ["get", "watch", "list"]
  }

  rule {
    api_groups = [""]
    resources  = ["pods"]
    verbs      = ["get", "watch", "list"]
  }

  rule {
    api_groups = ["extensions"]
    resources  = ["ingresses"]
    verbs      = ["get", "watch", "list"]
  }

  rule {
    api_groups = [""]
    resources  = ["nodes"]
    verbs      = ["list"]
  }
}

resource "kubernetes_cluster_role_binding" "external_dns" {
  metadata {
    name = "external-dns-viewer"
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = "external-dns"
  }
  subject {
    kind      = "ServiceAccount"
    name      = "external-dns"
    namespace = "default"
  }
}

resource "kubernetes_deployment" "external_dns" {
  metadata {
    name = "external-dns"
    labels = {
      app = "external-dns"
    }
  }

  spec {
    replicas = 1

    selector {
      match_labels = {
        app = "external-dns"
      }
    }

    strategy {
      type = "Recreate"
    }

    template {
      metadata {
        labels = {
          app = "external-dns"
        }
      }

      spec {
        service_account_name = "external-dns"
        container {
          name  = "external-dns"
          image = "registry.opensource.zalan.do/teapot/external-dns:latest"

          args = ["--source=service", "--source=ingress", "--provider=digitalocean"]

          env {
            name = "DO_TOKEN"
            value_from {
              secret_key_ref {
                name = "do-token"
                key  = "token"
              }
            }

          }

        }
      }
    }
  }
}

When I visit the dashboard, I get the following errors in the logs of the external DNS container:
time="2019-08-05T03:15:29Z" level=info msg="config: {Master: KubeConfig: RequestTimeout:30s IstioIngressGatewayServices:[istio-system/istio-ingressgateway] Sources:[service ingress] Namespace: AnnotationFilter: FQDNTemplate: CombineFQDNAndAnnotation:false IgnoreHostnameAnnotation:false Compatibility: PublishInternal:false PublishHostIP:false ConnectorSourceServer:localhost:8080 Provider:digitalocean GoogleProject: DomainFilter:[] ExcludeDomains:[] ZoneIDFilter:[] AlibabaCloudConfigFile:/etc/kubernetes/alibaba-cloud.json AlibabaCloudZoneType: AWSZoneType: AWSZoneTagFilter:[] AWSAssumeRole: AWSBatchChangeSize:1000 AWSBatchChangeInterval:1s AWSEvaluateTargetHealth:true AWSAPIRetries:3 AWSPreferCNAME:false AzureConfigFile:/etc/kubernetes/azure.json AzureResourceGroup: CloudflareProxied:false CloudflareZonesPerPage:50 RcodezeroTXTEncrypt:false InfobloxGridHost: InfobloxWapiPort:443 InfobloxWapiUsername:admin InfobloxWapiPassword: InfobloxWapiVersion:2.3.1 InfobloxSSLVerify:true InfobloxView: InfobloxMaxResults:0 DynCustomerName: DynUsername: DynPassword: DynMinTTLSeconds:0 OCIConfigFile:/etc/kubernetes/oci.yaml InMemoryZones:[] PDNSServer:http://localhost:8081 PDNSAPIKey: PDNSTLSEnabled:false TLSCA: TLSClientCert: TLSClientCertKey: Policy:sync Registry:txt TXTOwnerID:default TXTPrefix: Interval:1m0s Once:false DryRun:false LogFormat:text MetricsAddress::7979 LogLevel:info TXTCacheInterval:0s ExoscaleEndpoint:https://api.exoscale.ch/dns ExoscaleAPIKey: ExoscaleAPISecret: CRDSourceAPIVersion:externaldns.k8s.io/v1alpha1 CRDSourceKind:DNSEndpoint ServiceTypeFilter:[] CFAPIEndpoint: CFUsername: CFPassword: RFC2136Host: RFC2136Port:0 RFC2136Zone: RFC2136Insecure:false RFC2136TSIGKeyName: RFC2136TSIGSecret: RFC2136TSIGSecretAlg: RFC2136TAXFR:false NS1Endpoint: NS1IgnoreSSL:false TransIPAccountName: TransIPPrivateKeyFile:}"
time="2019-08-05T03:15:29Z" level=fatal msg="invalid configuration: no configuration has been provided"

When I visit the Kubernetes dashboard, I can confirm that DO_TOKEN is 64 bytes in length and is the correct value.  Help!  Thank you in advance.

Of course, after posting the issue I found out what was going on.  The problem is not with external-dns but instead with Terraform.  There is a workaround for the bug (automount_service_account_token = true in the same section as `service_account_name = "external-dns") and the workaround does indeed work.  Sorry to waste your time!

@mathuin No worries, thanks for reporting it and also posting the solution. Other people might stumble on that and find your answer helpful.

authors: linki mathuin

repo: kubernetes-incubator/external-dns


text:
Cloudflare proxied annotation broken?

Related to #650
I've tried a lot to actually make the recently released annotation based proxy work. Didn't succeed :/
Setting external-dns.alpha.kubernetes.io/cloudflare-proxied: "true" on my Ingress annotation doesn't change anything. Both ways, actually. So neither overriding a default false with true nor overriding a default true with false seems to work.
Installed using a helm chart with the following values:
## Details about the image to be pulled.
image:
  name: registry.opensource.zalan.do/teapot/external-dns
  tag: v0.5.9
  pullSecrets: []
  pullPolicy: IfNotPresent

## This controls which types of resource external-dns should 'watch' for new
## DNS entries.
sources:
  - ingress

# Allow external-dns to publish DNS records for ClusterIP services (optional)
publishInternalServices: false

## The DNS provider where the DNS records will be created (options: aws, google, inmemory, azure, rfc2136 )
provider: cloudflare

# Configuration for OpenStack Designate provider
designate:
  # A custom CA (optional)
  customCA:
    # Turn custom CA on or off
    enabled: false
    # The content of the custom CA file
    content: ""
    # Location to mount custom CA
    directory: "/config/designate"
    # Filename of the custom CA
    filename: "designate-ca.pem"

## Limit possible target zones by domain suffixes (optional)
domainFilters: []
## Limit possible target zones by zone id (optional)
zoneIdFilters: []
# Filter sources managed by external-dns via annotation using label selector semantics (default: all sources)
annotationFilter: ""
## Adjust the interval for DNS updates
interval: "1m"

# Registry to use for ownership (txt or noop)
registry: "txt"

# When using the TXT registry, a name that identifies this instance of ExternalDNS
txtOwnerId: ""

# When enabled, prints DNS record changes rather than actually performing them
dryRun: false

## Node labels for pod assignment
## Ref: https://kubernetes.io/docs/user-guide/node-selection/
##
nodeSelector: {}

## List of node taints to tolerate (requires Kubernetes >= 1.6)
tolerations: []

## Modify how DNS records are sychronized between sources and providers (options: sync, upsert-only )
policy: upsert-only

## Annotations to be added to pods
##
podAnnotations: {}

podLabels: {}

# Verbosity of the logs (options: panic, debug, info, warn, error, fatal)
logLevel: info

extraArgs: {}

# Extra environment variables which will be saved in a release-specific secret
# or retrieved via valueFrom.
# extraEnv:
# - name: SECRET_TO_SAVE
#   value: secret_value
# - name: AWS_ACCESS_KEY_ID
#   valueFrom:
#     secretKeyRef:
#       name: existing-secret
#       key: access-key-id
extraEnv: []

## CPU and Memory limit and request for external-dns
resources: {}
#  limits:
#    memory: 50Mi
#  requests:
#    memory: 50Mi
#    cpu: 10m

rbac:
  ## If true, create & use RBAC resources
  ##
  create: true
  # Beginning with Kubernetes 1.8, the api is stable and v1 can be used.
  apiVersion: v1beta1

  ## Ignored if rbac.create is true
  ##
  serviceAccountName: default

securityContext:
  {}
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 65534 # 65534 is nobody - revise aws.credentialsPath when changing uid
  # capabilities:
  #   drop: ["ALL"]

service:
  annotations: {}
  clusterIP: ""

  ## List of IP addresses at which the service is available
  ## Ref: https://kubernetes.io/docs/user-guide/services/#external-ips
  ##
  externalIPs: []

  loadBalancerIP: ""
  loadBalancerSourceRanges: []
  servicePort: 7979
  type: ClusterIP

priorityClassName: ""

Any ideas? Am I missing something?

The annotation should definitely be working.
Perhaps you can share the Ingress resource where you have the annotation set, and also the resulting DNS records created in Cloudflare?
You might also get more useful info if you turn debug logging up to debug, but no guarantees.

Put it to debug. But doesn't log anything related to cf proxy settings.
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: another-demo.example.io
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"
spec:
  tls:
    - hosts:
        - another-demo.example.io
      secretName: another-demo-k8s-tls
  rules:
    - host: another-demo.example.io
      http:
        paths:
          - path: /
            backend:
              serviceName: demo-svc-another
              servicePort: 80

describe ingress includes correct annotation:
...

Annotations:
  ...

  kubernetes.io/ingress.class:                          nginx
  kubernetes.io/tls-acme:                               true
  external-dns.alpha.kubernetes.io/cloudflare-proxied:  true

Is the record successfully created in Cloudflare just with proxying disabled, or is it not created at all?
Also worth considering the below:

If your Cloudflare plan for your zone allows/includes proxying capabilities
If the record is for a private IP, in which case proxying won't be allowed
Try deleting the existing record entirely if possible (In case it's an issue changing from non-proxied to proxied... though I recently tested this myself)

Record creation/deletion/update is fine. He does that every minute according to logs.
I don't think thats a permission issue, since he does change (existing) records' proxy setting in the next update cycle after I've changed it in the default settings. It's just that the overrides from the annotations don't have any effect.

@alexanderbuhler Are you saying that if the ingress and record are created, but then you later change the annotations, the record is not updated? Or that the annotation is not respected when the ingress is first created? Can you kubectl describe your container and ingress?

@afirth Doesn't matter whether initially or later on. The annotation is not beeing taken into account.
Ingress:
Name:             rabbitproxy.hrg-dev.XXX.io
Namespace:        ext
Address:          195.192.XXX.XXX
Default backend:  default-http-backend:80 (<none>)
TLS:
  rabbitproxy-dev-tls terminates rabbitproxy.hrg-dev.XXX.io
Rules:
  Host                          Path  Backends
  ----                          ----  --------
  rabbitproxy.hrg-dev.XXX.io
                                /   rabbitmq:17835 (<none>)
Annotations:
  external-dns.alpha.kubernetes.io/cloudflare-proxied:  true
  kubectl.kubernetes.io/last-applied-configuration:     {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"external-dns.alpha.kubernetes.io/cloudflare-proxied":"true","kubernetes.io/ingress.class":"nginx","kubernetes.io/tls-acme":"true","nginx.ingress.kubernetes.io/ssl-passthrough":"true"},"name":"rabbitproxy.hrg-dev.XXX.io","namespace":"ext"},"spec":{"rules":[{"host":"rabbitproxy.hrg-dev.XXX.io","http":{"paths":[{"backend":{"serviceName":"rabbitmq","servicePort":17835},"path":"/"}]}}],"tls":[{"hosts":["rabbitproxy.hrg-dev.XXX.io"],"secretName":"rabbitproxy-dev-tls"}]}}

  kubernetes.io/ingress.class:                  nginx
  kubernetes.io/tls-acme:                       true
  nginx.ingress.kubernetes.io/ssl-passthrough:  true
Events:                                         <none>

Container:
Name:               external-dns-controller-external-dns-68d79d5447-w5msd
Namespace:          external-dns
Priority:           0
PriorityClassName:  <none>
Node:               silly-turing-797f494fcb-fp56g/192.168.1.3
Start Time:         Tue, 16 Apr 2019 12:38:20 +0200
Labels:             app=external-dns
                    heritage=Tiller
                    pod-template-hash=68d79d5447
                    release=external-dns-controller
Annotations:        <none>
Status:             Running
IP:                 172.25.9.11
Controlled By:      ReplicaSet/external-dns-controller-external-dns-68d79d5447
Containers:
  external-dns:
    Container ID:  docker://2130ee0cb0c1f4a1e251514204b50073caaa2fbe308ddbfb513f6e5e0a75165a
    Image:         registry.opensource.zalan.do/teapot/external-dns:v0.5.9
    Image ID:      docker-pullable://registry.opensource.zalan.do/teapot/external-dns@sha256:3238aaf10240d6322c87073766f67d8cf24dc2db4f0ef01b62d18890573f8075
    Port:          7979/TCP
    Host Port:     0/TCP
    Args:
      --log-level=info
      --policy=upsert-only
      --provider=cloudflare
      --registry=txt
      --interval=1m
      --source=ingress
    State:          Running
      Started:      Tue, 16 Apr 2019 12:41:30 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      memory:  50Mi
    Requests:
      cpu:     10m
      memory:  50Mi
    Liveness:  http-get http://:7979/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      CF_API_KEY:    <set to the key 'cloudflare_api_key' in secret 'external-dns-controller-external-dns'>  Optional: false
      CF_API_EMAIL:  XXXXXX@XXXXX.XX
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from external-dns-controller-external-dns-token-lr6s9 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  external-dns-controller-external-dns-token-lr6s9:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  external-dns-controller-external-dns-token-lr6s9
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

Was created with those annotations. Logs on level info:
time="2019-04-18T15:04:33Z" level=info msg="Changing record." action=CREATE record=rabbitproxy.hrg-dev.onexp.io ttl=1 type=A zone=beb2a7301a2b3bb7f2e3cb1ce33aa33b
time="2019-04-18T15:04:34Z" level=info msg="Changing record." action=CREATE record=rabbitproxy.hrg-dev.onexp.io ttl=1 type=TXT zone=beb2a7301a2b3bb7f2e3cb1ce33aa33b

Image:         registry.opensource.zalan.do/teapot/external-dns:v0.5.9
Image ID:
docker-pullable://registry.opensource.zalan.do/teapot/external-dns@sha256:3238aaf10240d6322c87073766f67d8cf24dc2db4f0ef01b62d18890573f8075
Looks like you might have an old image version. Try 5.12?
On Fri, Apr 19, 2019, 11:36 alexanderbuhler notifications@github.com
wrote:

@afirth https://github.com/afirth Doesn't matter whether initially or
later on. The annotation is not beeing taken into account.
Ingress:
Name:             rabbitproxy.hrg-dev.XXX.ioNamespace:        extAddress:          195.192.XXX.XXXDefault backend:  default-http-backend:80 ()TLS:
rabbitproxy-dev-tls terminates rabbitproxy.hrg-dev.XXX.ioRules:
Host                          Path  Backends

rabbitproxy.hrg-dev.XXX.io
/   rabbitmq:17835 ()Annotations:
external-dns.alpha.kubernetes.io/cloudflare-proxied:  true
kubectl.kubernetes.io/last-applied-configuration:     {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"external-dns.alpha.kubernetes.io/cloudflare-proxied":"true","kubernetes.io/ingress.class":"nginx","kubernetes.io/tls-acme":"true","nginx.ingress.kubernetes.io/ssl-passthrough":"true"},"name":"rabbitproxy.hrg-dev.XXX.io","namespace":"ext"},"spec":{"rules":[{"host":"rabbitproxy.hrg-dev.XXX.io","http":{"paths":[{"backend":{"serviceName":"rabbitmq","servicePort":17835},"path":"/"}]}}],"tls":[{"hosts":["rabbitproxy.hrg-dev.XXX.io"],"secretName":"rabbitproxy-dev-tls"}]}}
kubernetes.io/ingress.class:                  nginx
kubernetes.io/tls-acme:                       true
nginx.ingress.kubernetes.io/ssl-passthrough:  trueEvents:
Container:
Name:               external-dns-controller-external-dns-68d79d5447-w5msdNamespace:          external-dnsPriority:           0PriorityClassName:  Node:               silly-turing-797f494fcb-fp56g/192.168.1.3Start Time:         Tue, 16 Apr 2019 12:38:20 +0200Labels:             app=external-dns
heritage=Tiller
pod-template-hash=68d79d5447
release=external-dns-controllerAnnotations:        Status:             RunningIP:                 172.25.9.11Controlled By:      ReplicaSet/external-dns-controller-external-dns-68d79d5447Containers:
external-dns:
Container ID:  docker://2130ee0cb0c1f4a1e251514204b50073caaa2fbe308ddbfb513f6e5e0a75165a
Image:         registry.opensource.zalan.do/teapot/external-dns:v0.5.9
Image ID:      docker-pullable://registry.opensource.zalan.do/teapot/external-dns@sha256:3238aaf10240d6322c87073766f67d8cf24dc2db4f0ef01b62d18890573f8075
Port:          7979/TCP
Host Port:     0/TCP
Args:
--log-level=info
--policy=upsert-only
--provider=cloudflare
--registry=txt
--interval=1m
--source=ingress
State:          Running
Started:      Tue, 16 Apr 2019 12:41:30 +0200
Ready:          True
Restart Count:  0
Limits:
memory:  50Mi
Requests:
cpu:     10m
memory:  50Mi
Liveness:  http-get http://:7979/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
CF_API_KEY:    <set to the key 'cloudflare_api_key' in secret 'external-dns-controller-external-dns'>  Optional: false
CF_API_EMAIL:  XXXXXX@XXXXX.XX
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from external-dns-controller-external-dns-token-lr6s9 (ro)Conditions:
Type              Status
Initialized       True
Ready             True
ContainersReady   True
PodScheduled      True Volumes:
external-dns-controller-external-dns-token-lr6s9:
Type:        Secret (a volume populated by a Secret)
SecretName:  external-dns-controller-external-dns-token-lr6s9
Optional:    falseQoS Class:       BurstableNode-Selectors:  Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300sEvents:
Was created with those annotations. Logs on level info:
time="2019-04-18T15:04:33Z" level=info msg="Changing record." action=CREATE record=rabbitproxy.hrg-dev.onexp.io ttl=1 type=A zone=beb2a7301a2b3bb7f2e3cb1ce33aa33b
time="2019-04-18T15:04:34Z" level=info msg="Changing record." action=CREATE record=rabbitproxy.hrg-dev.onexp.io ttl=1 type=TXT zone=beb2a7301a2b3bb7f2e3cb1ce33aa33b
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/external-dns/issues/940#issuecomment-484828550,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN4P4DZIHSKYNXLVR7Y6D3PRGHARANCNFSM4HAQZ6LQ
.

5.12 fixes this issue for me. Thank you.

authors: Evesy afirth alexanderbuhler


text:
Disable sshd password authentication by default

https://github.com/coreos/bugs/issues/2114

@jeremyd Any chance you could send a PR for this? 😄

Ah, thanks for the reminder, I had forgotten to PR it :)

authors: jeremyd mumoshu

repo: kubernetes-incubator/kube-aws


text:
e2e: Add support for toggling RBAC

Used while investigating #874

Codecov Report

Merging #876 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #876   +/-   ##
=======================================
  Coverage   34.69%   34.69%
=======================================
  Files          57       57
  Lines        3914     3914
=======================================
  Hits         1358     1358
  Misses       2396     2396
  Partials      160      160

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 09a4651...2cdea73. Read the comment docs.

authors: codecov-io mumoshu


text:
Turn Swap off

Kubespray is returning swap enabled error since on most of the OS by default Swapp is on,
Turing Swapp off as a part of OS provisioning,

sorry  fix  in  #2903

authors: mrafieee riverzhang

repo: kubernetes-incubator/kubespray


text:
EKS installation requires InternalIP

Fixes https://github.com/kubernetes-incubator/metrics-server/issues/170

/retest

wouldn't it also require:
            - --kubelet-insecure-tls
or the one present only in master for now:
            - --kubelet-certificate-authority /etc/kubernetes/pki/ca.crt
?

Right, I don't think this should be the default for everyone though, and especially we shouldn't just be locking to internalip only

@DirectXMan12 Agree
have left it an PR for EKS users to refer.

repo: kubernetes-incubator/metrics-server


text:
Client work

We need this for our auto generated client to work
This includes the chanegs to the generated code as a second commit. Deletions are in the same as #352

Thanks for doing this.
Command decision - merging

authors: MHBauer pmorie

repo: kubernetes-incubator/service-catalog


text:
s|github.com/kubernetes-sigs|sigs.k8s.io

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind test
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:
With blobfuse-csi-driver migrated to kubernetes-sigs org, we should change the package prefix from github.com/kubernetes-sigs to sigs.k8s.io. This PR is necessary
Which issue(s) this PR fixes:

Related issue: https://github.com/kubernetes-sigs/blobfuse-csi-driver/issues/9
Special notes for your reviewer:
Release note:
None.

I'll retest this PR once https://github.com/kubernetes/test-infra/pull/15776 is merged.

/retest

/test pull-blobfuse-csi-driver-e2e

@andyzhangx this PR should be safe to merge manually as #89 depends on it.

authors: andyzhangx chewong

repo: kubernetes-sigs/blobfuse-csi-driver


text:
My proxmox provider allows me to set NODE_IP_RANGES: "[10.4.0.20-10.4.0.254]", would also like to set a VIP_IP_RANGES.

Describe the solution you'd like
Seems ipam is already capable of supporting this.  I think maybe the ipam project just isn't encouraging providers to implement it
I'd like the ipam project to add the documentation and stubbed out methods, whatever is necessary to encourage providers to also implement setting the vip, in addition to the node ips.
Anything else you would like to add:
I wouldn't be surprised if the proxmox provider already implements this, but I'm finding a lack of documentation and slack channel responses.  I think I might have read that it was a non-goal.  I'd like that to be added as a goal.  The ipam project would only have to decide, they wouldn't need to force anyone.  Without the vip being set automatically I'm having to look for available ips and set it myself each time, which is exactly what ipam solved for node ips.
It would be easier for me to ask the cluster-api provider to add a feature defined by the ipam project than to create something unique for just myself.  If I am to be the implementor of the feature for the provider, similarly I'd like to follow a standard so I wouldn't just be implementing something unique for a single provider.  I had the same need when using the vsphere provider, and I suspect its pretty much the same for all providers.
/kind feature

I envision a couple possibilities, on a namespace level, there could be one or more InClusterIPPools each with labels to indicate:

cluster-api-vm-ip
cluster-api-vip
One or both labels could be applied, and used by a provider to get the vip or vm ips.  And, based on which namespace the cluster is deployed to, the InClusterIPPools would be the source of ips.

Alternatively, if no namespace level InClusterIPPools exist, GlobalInClusterIPPools could be used in the same way, also with labels.
...
I hear what you are saying that the different environments are just so different is hard to standardize.
It really sems like getting a vip should part of cluster-api standard, or ipam standard.
I can enhance proxmox, given that's the provider I'm using, but seems like that'd be a one off when there should be more of an over all "every provider benefits".  I don't think anyone really wants to specify a vip or vm ips when spinning up the cluster, feels like something that should be automated.
Just trying to think of the best way to get this feature added in.

Created a feature request on proxmox provider github page, though it really feels like this should be more at a cluster-api level:
https://github.com/ionos-cloud/cluster-api-provider-proxmox/issues/304


text:
Fix CRI-O get script location

What type of PR is this?
/kind failing-test
What this PR does / why we need it:
Fixing the script location after its removal.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

@kubernetes-sigs/cri-tools-maintainers PTAL

/lgtm

authors: haircommander saschagrunert

repo: kubernetes-sigs/cri-tools


text:
Add conformance report for NGINX Gateway Fabric v1.5.0

What type of PR is this?
/area conformance
What this PR does / why we need it:
Updates conformance report for NGINX Gateway Fabric v1.5.0
Does this PR introduce a user-facing change?:
NO
NONE

/ok-to-test

/approve

/retest

Hmm, that should not be failing on that docker build step, could you rebase from main and force push?

Thanks @salonichf5!
/lgtm

authors: robscott salonichf5 youngnick

repo: kubernetes-sigs/gateway-api


text:
Enable elder e2e tests in CI

What this PR does / why we need it:
Enable elder e2e tests in Travis.
Special notes for your reviewer:
Release note:

None

/assign k82cn

@TommyLike this change looks good.
The test case 'Try to fit unassigned task with different resource requests in one loop' is failing due to task priority.
To pass the test case we need to swap the workerPriority with masterPriority.
But i am not sure if this test was passing earlier, then there could be a bug in the kube-batch?
Why its failing:
If you see the below code the replicaset will fill the pods with onecpu across all the nodes.
And it will leave only one slot empty which is 'one cpu core', then test tries to create the job with two task one with higher prirority and the other with lower priority.
But the task with higher priority cant be scheduled since it requests Two cpu-cores there is only one cpu core only left in the cluster in some node. So it blocks the other task also resulting in both of them not getting scheduled.
https://github.com/kubernetes-sigs/kube-batch/blob/5b048be1b1d15fa03e84b6ea722733b7c87205bb/test/e2e/kube-batch/job.go#L64-L95

@TommyLike i will raise a pr with the fix for the test case failure.
But i need to confirm is that the actual/correct behaviour?
And if so how was this passing all this time?

@shivramsrivastava not sure, it's working on my local environment.

@TommyLike it fails in my local environment ( kind cluster) consistently.

=== RUN   TestE2E
Running Suite: volcano Test Suite
=================================
Random Seed: 1556100102
Will run 1 of 4 specs

S
------------------------------
• Failure [87.406 seconds]
Job E2E Test
/home/root1/gopathPoseidon/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/job.go:23
  Try to fit unassigned task with different resource requests in one loop [It]
  /home/root1/gopathPoseidon/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/job.go:64

  Cluster Info:
    Nodes:

      Name: shiv-control-plane
      Allocatable:
        Pods: 110
        CPU: 4
        Memory: 16297844Ki
      Conditions:
        NetworkUnavailable=False
        MemoryPressure=False
        DiskPressure=False
        PIDPressure=False
        Ready=True
      Taints:
        node-role.kubernetes.io/master  NoSchedule

      Name: shiv-worker
      Allocatable:
        Pods: 110
        CPU: 4
        Memory: 16297844Ki
      Conditions:
        NetworkUnavailable=False
        MemoryPressure=False
        DiskPressure=False
        PIDPressure=False
        Ready=True
      Taints:

      Name: shiv-worker2
      Allocatable:
        Pods: 110
        CPU: 4
        Memory: 16297844Ki
      Conditions:
        NetworkUnavailable=False
        MemoryPressure=False
        DiskPressure=False
        PIDPressure=False
        Ready=True
      Taints:

      Name: shiv-worker3
      Allocatable:
        Pods: 110
        CPU: 4
        Memory: 16297844Ki
      Conditions:
        NetworkUnavailable=False
        MemoryPressure=False
        DiskPressure=False
        PIDPressure=False
        Ready=True
      Taints:

    Pods:
      coredns-86c58d9df4-chr2m                     kube-system    Running   shiv-control-plane
      coredns-86c58d9df4-v59wz                     kube-system    Running   shiv-control-plane
      etcd-shiv-control-plane                      kube-system    Running   shiv-control-plane
      kube-apiserver-shiv-control-plane            kube-system    Running   shiv-control-plane
      kube-controller-manager-shiv-control-plane   kube-system    Running   shiv-control-plane
      kube-proxy-d5sjb                             kube-system    Running   shiv-worker2
      kube-proxy-kq7c8                             kube-system    Running   shiv-worker
      kube-proxy-wt27b                             kube-system    Running   shiv-worker3
      kube-proxy-xwbbl                             kube-system    Running   shiv-control-plane
      kube-scheduler-shiv-control-plane            kube-system    Running   shiv-control-plane
      weave-net-42jd4                              kube-system    Running   shiv-worker2
      weave-net-9qj7r                              kube-system    Running   shiv-worker3
      weave-net-bxglq                              kube-system    Running   shiv-control-plane
      weave-net-szl8s                              kube-system    Running   shiv-worker
      multi-task-diff-resource-job-0-c97kr         test           Pending
      multi-task-diff-resource-job-1-q2hq6         test           Pending
      rs-1-c2szf                                   test           Running   shiv-worker
      rs-1-g7x6d                                   test           Running   shiv-worker2
      rs-1-k7gcm                                   test           Running   shiv-worker3
      rs-1-mq8zq                                   test           Running   shiv-worker3
      rs-1-nm88z                                   test           Running   shiv-worker2
      rs-1-rkmqw                                   test           Running   shiv-worker3
      rs-1-w5sbt                                   test           Running   shiv-worker
      rs-1-wqspw                                   test           Running   shiv-worker

  Expected error:
      <*errors.errorString | 0xc00007b700>: {
          s: "timed out waiting for the condition",
      }
      timed out waiting for the condition
  not to have occurred

  /home/root1/gopathPoseidon/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/job.go:102
------------------------------
SS

Summarizing 1 Failure:

[Fail] Job E2E Test [It] Try to fit unassigned task with different resource requests in one loop
/home/root1/gopathPoseidon/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/job.go:102

Ran 1 of 4 Specs in 87.406 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 3 Skipped
--- FAIL: TestE2E (87.41s)
FAIL
FAIL	github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch	87.415s
hack/run-e2e.sh: line 15: 20922 Killed                  nohup ${KA_BIN}/kube-batch --kubeconfig ${HOME}/.kube/config --scheduler-conf=config/kube-batch-conf.yaml --logtostderr --v ${LOG_LEVEL} > scheduler.log 2>&1

It's unstable or have deeper root cause which we can't identify for now, tested it can work with my environment:
Running Suite: volcano Test Suite
=================================
Random Seed: 1556160960
Will run 2 of 2 specs

this is the cluster size 12• [SLOW TEST:33.914 seconds]
Job E2E Test
/root/go_projects/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/job.go:25
  Try to fit unassigned task with different resource requests in one loop
  /root/go_projects/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/job.go:26
------------------------------
S [SKIPPING] [0.000 seconds]
Job E2E Test
/root/go_projects/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/benchmark.go:51
  [Feature:Performance] Schedule Density Job [It]
  /root/go_projects/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/benchmark.go:52

  Performance test skipped since config file not found

  /root/go_projects/src/github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch/benchmark.go:54
------------------------------

Ran 1 of 2 Specs in 33.915 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 1 Skipped
--- PASS: TestE2E (33.91s)
PASS
ok  	github.com/kubernetes-sigs/kube-batch/test/e2e/kube-batch	33.925s

@k82cn  your call.

This patch is not required anymore, due to the merge of #806

authors: TommyLike shivramsrivastava

repo: kubernetes-sigs/kube-batch


text:
Improve liveness and readiness probes accuracy

What would you like to be added:
The liveness and readiness probes should succeed only when the operator is fully operational. This means they should report a health status only when all the components, i.e, webhooks, extension API servers, controllers, have started and are servicing requests.
Why is this needed:
At the moment, the liveness and readiness probes report a healthy status unconditionally, as soon as the controller-runtime manager has started, despite the operator and its components (webhooks, extension API servers, controllers) may not be operational yet.
That can happen over the period of time it takes for the certificates generated by cert-controller to be propagated into the secret volume mount for example.
In such cases, having the probes reporting an accurate status can help recovering issues, and other components correctly waiting for the operator readiness.
Completion requirements:
This enhancement requires the following artifacts:

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

The artifacts should be linked in subsequent comments.

I believe this issue is already address with https://github.com/kubernetes-sigs/kueue/pull/1676 (and cherry-picked to 0.5.x)/
@astefanutti PTAL, if so then we can close.

@mimowo thanks for the update. I'd say #1676 fixes most of this issue.
There are a couple of things in the scope of this issue that we may still want to address like:

Including the status of the visibility API server in the readiness check
Improving the accuracy / usefulness of the liveness check

So I think we can close this one, and we can create some finer-grained ones for the two left-overs above. WDYT?

Including the status of the visibility API server in the readiness check

Seems like a valid improvement indeed, otherwise we may be getting errors from the server.

Agreed.

Improving the accuracy / usefulness of the liveness check
Any concrete example, other than the visibility API server, where we could improve accuracy?

I wonder if probing for the webhooks in the liveness probe, as done in the readiness probe now with #1676, would be useful to mitigate the situation where cert-controller might fail generating / injecting the certificates at start time, and possibly over cert rotation. Do you think that would be an improvement over the current liveness probe implementation?

So I think we can close this one, and we can create some finer-grained ones for the two left-overs above. WDYT?

I prefer more fine-grained issues, so that we can prioritize / close them independently.

Sounds good, I'll create them and close this one.

I wonder if probing for the webhooks in the liveness probe

Oh, interesting. I assumed the liveness probe = readiness probe, but it indeed the liveness probe = health probe in controller manager: https://github.com/kubernetes-sigs/controller-runtime/blob/7032a3cc91d2afc4c2d54e4a4891cf75da9f75f5/pkg/manager/internal.go#L281-L285.
And currently, the health probe is just ping in Kueue. So, yes I think using the liveness probe checking webhook server is better so that we can see if the server is down. cc @trasc @alculquicondor

/remove-lifecycle stale

/assign

@astefanutti  since this question was posted we have added the readiness probe to Kueue in https://github.com/kubernetes-sigs/kueue/pull/1676 (and later improved in follow ups).
Do we still have some known gaps to cover in the readiness probe, or scenarios that we want to cover in the liveness probe?
If not, I would suggest to park  this issue (close) until we have such scenarios.

@mimowo apologies for the late reply.
I think what's been done to improve the readiness mostly addresses this issue, and I agree with your suggestion to close it, and create some finer-grained ones if needed.

/close

authors: astefanutti mbobrovskyi mimowo tenzen-y

repo: kubernetes-sigs/kueue


text:
Kueue should be able to install into different namespace

What happened:
Kueue can only installed in kueue-system namespace
If install it into a different namespace webhook will failed
Error from server (InternalError): error when creating "mykueue.yaml": Internal error occurred: failed calling webhook "mresourceflavor.kb.io": failed to call webhook: Post "https://kueue-webhook-service.mynamespace.svc:443/mutate-kueue-x-k8s-io-v1beta1-resourceflavor?timeout=10s": no endpoints available for service "kueue-webhook-service"

What you expected to happen:
To work on different namespace
How to reproduce it (as minimally and precisely as possible):
$ helm install kueue oci://us-central1-docker.pkg.dev/k8s-staging-images/charts/kueue \
  --version="v0.9.1" \
  --create-namespace \
  --namespace=mynamespace

$ cat mykueue.yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: default-flavor

$ kubectl apply -n mynamespace -f mykueue.yaml
Error from server (InternalError): error when creating "mykueue.yaml": Internal error occurred: failed calling webhook "mresourceflavor.kb.io": failed to call webhook: Post "https://kueue-webhook-service.mynamespace.svc:443/mutate-kueue-x-k8s-io-v1beta1-resourceflavor?timeout=10s": no endpoints available for service "kueue-webhook-service"

Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version): v1.30.1
Kueue version (use git describe --tags --dirty --always): 0.9.1
Cloud provider or hardware configuration: x86_64
OS (e.g: cat /etc/os-release): Ubuntu 22.04.5 LTS
Kernel (e.g. uname -a): Linux 6.8.0-49-generic
Install tools: Helm
Others:

I'm trying to reproduce this issue:
$ helm install kueue oci://us-central1-docker.pkg.dev/k8s-staging-images/charts/kueue \
  --version="v0.9.1" \
  --create-namespace \
  --namespace=mynamespace

$ k apply -f mykueue.yaml

Looks like working fine.

@mbobrovskyi I forgot to include namespace in applying yaml file
the command should be $ kubectl apply -n mynamespace -f mykueue.yaml(I've also update the original post)

@mbobrovskyi I forgot to include namespace in applying yaml file the command should be $ kubectl apply -n mynamespace -f mykueue.yaml(I've also update the original post)

You don't need namespace for resourceflavor. This is cluster-scoped resource.
Anyway, it works for me too.
kubectl apply -n mynamespace -f mykueue.yaml
resourceflavor.kueue.x-k8s.io/default-flavor created

I think I found the issue, it's because kueue webhook service is not ready yet, so resource flavor will not install successfully
Thanks


text:
fix(plugins/plugin-s3): ibm s3 provider registers too late

Fixes #7560

Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[x] 🐛 Bug fix
[ ] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

/lgtm

repo: kubernetes-sigs/kui


text:
improve: test

I improved tests.

/ok-to-test

/retest

/retest

/retest

authors: sivchari wzshiming

repo: kubernetes-sigs/kwok


text:
Refactoring the Kubelet Service interface

What type of PR is this?

/kind cleanup
What this PR does / why we need it:
Which issue(s) this PR fixes:

xref #162
Special notes for your reviewer:
The original interface copied from Kubelet is not suitable for the kwok, so some changes have been made
/cc @nikola-jokic
Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

Great! I'll fix the PR as soon as this is merged :relaxed:

authors: nikola-jokic wzshiming


text:
[Question] Disable webhook deployment

I'm sorry if i put the query on this section

What the impact if we disable webhook deployment?, if we only use seccomp feature (for now) for the profile distribution only without profilebinding, etc.? is it safe?,
I tried locally, i still could create/delete the seccompprofile.
Thanks

It should work if you plan to only install the profile but don't do any recording. Also there is an option to disable the dynamic webhook created by the operator and deploy a static webhook via the deployment. You can have a look at https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/webhook-operator.yaml. Thanks

Thank you @ccojocar!


text:
DeploymentStatus readyReplicas docstring needs clarification.

https://github.com/kubernetes/api/blob/master/apps/v1/types.go#L411
The docstring defines readyReplicas as "Total number of ready pods targeted by this deployment" which is defining "ready" in terms of being "ready".  Please clarify the docstring on what "ready" means in this context since the docstring is used for the user-facing docs at https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/deployment-v1/.
Fixing this will also resolve https://github.com/kubernetes/website/issues/28316

/good-first-issue

/assign

@briantkennedy As I understood, the documentation should be clarified to describe that a pod is defined as ready when it's passing the defined probes. Is that correct?
By reviewing the mentioned page Deployment, I saw that  ReplicaSet#ReplicaSetStatus, ReplicationController#ReplicationControllerStatus, and DaemonSet#DaemonSetStatus have similar descriptions with an equivalent grade of unclarity.
I would suggest rewriting all those docs to something like readyReplicas is the number of Pods targeted by this Deployment that have a Ready Condition. equivalent to the docs of StatefulSet#StatefulSetStatus.
If you approve this, I will open a PR and do it for all the mentioned docs.

Thanks for taking a look.  You are correct, adding the criteria for ready is what I'm looking for.  For clarity, what are the defined probes you are referring to?

I'm referring to the readiness probes. Thanks for the Feedback, the PR will follow soon.

authors: briantkennedy matthiasgubler nikhita

repo: kubernetes/api


text:
[stable/minecraft] Use storageClassName for minecraft.

Fixed minecraft for #1869
/cc @prydonius

/lgtm

repo: kubernetes/charts


text:
Minor Keel upgrade 0.4.2 -> 0.4.7

Minor Keel upgrade to cover this issue https://github.com/keel-hq/keel/issues/50

/ok-to-test
/lgtm

/lgtm

authors: Antiarchitect timstoop unguiculus


text:
Add periodic jobs for E2E conformance tests

What this PR does / why we need it:
Add periodic jobs for E2E conformance tests

test against kubernetes master
test against kubernetes latest release(v1.10.0)

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #103
Special notes for your reviewer:
@dims
Release note:

/ok-to-test

Current supported trigger comments, we can rerun the failed test jobs with specific comments.
https://github.com/theopenlab/cicd-howto#kubernetescloud-provider-openstack

/test cloud-provider-openstack-e2e-conformance

Ready to go

/approve

/test all

/test cloud-provider-openstack-all

/retest
/test all

/test all

/test all

/test all

/lgtm

authors: dims dixudx kiwik mrhillsman

repo: kubernetes/cloud-provider-openstack


text:
update tags to v1.26.0 release

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/lgtm

authors: jichenjc zetaab


text:
Support metric types with floating point in prometheus-to-sd

If we have Gauge of Counter type then we automatically assign to it int64 value type. Unfortunately there is no value type in the prometheus format, so we need to try to determine it base on the actual metric numbers.
/assign @loburm

Component was moved to the different repo.

repo: kubernetes/contrib


text:
Munge pr since last loop

I've tentatively explain what this does in the commit messages, please read those instead.

This change is

This is an attempt to improve the situation described by #1406

@eparis I'll try to clarify the idea
It looks like a Status change doesn't update the UpdateAt field of an issue/pr, which means that using the "Since" parameter, we won't get issues whose status as changed (but nothing else). And I assume this is a problem.
Listening to Status change webhooks event helps, but the problem is that it doesn't say what pull-requests are impacted by the status-change, just the commit sha. That's why I'm keeping track of "what issues are associated with what commit sha" so that I can say "Ah! This sha status has changed, it means these PRs have changed, we should probably also munge them."

Also, I only care about the HEAD because this is the status we are interested in.

@eparis I've updated the PR, and re-ordered the commits to maybe clarify the idea. I've also dropped the timer for now.
What this is doing:

Use "Since" so we only munge issues that have changed since last loop
Use webhooks and track StateChange so that we can munge issues whose HEAD commit status has changed.

Does it make more sense?

@eparis I tried to address your comment and give methods of StatusChange (that I renamed)  a better name.
Hopefully this goes in the right direction

@eparis I tried it with ngrok against kubernetes/kubernetes and fixed a couple of small bugs. This seems to be working now and definitely improves the token situation by orders of magnitude. Can we get that in?
Thanks

@eparis @rmmh Updated the PR to consider the following problem:
Some PR assume that they will receive the full list of open PRs (submit-queue, cherrypick-queue). I think I fixed this behavior.

Also, I realize this is currently being migrated to test-infra, I don't want to delay the review though. I'll diff/patch as soon as possible. But please feel free to start reviewing :-)


text:
Release go signal 06 March 2017

Prepare release go/no go signal report for 2017-03-06

lgtm!

authors: calebamiles ethernetdan

repo: kubernetes/features


text:
Need tiller binary distributed with each release

We want this feature to run tiller locally along with helm in same container/vm. We cannot use docker image of tiller due to our policies.

Will simply running make bootstrap build from source not work for your needs?

Thats how am building tiller binary right now. Its time taking sometimes as make bootstrap build clones entire kubernetes repo if we've to do clean build. And we've to track/build tiller version separately whenever there is a new version of helm (Not a big deal though).
So it would be great if we get binary distributed in each release.

Okay, there is a PR to add this as a separate build. We could just add a downloadable package. See #1722

Thank you very much... @technosophos

Added to meta issue #1968

@spothala Closing this since it appears fixed in PR #1798 and due to inactivity. Please feel free to re-open if necessary.

re-opening; #1798 is neither a PR nor does it actually fix the problem. In fact it redirects back to this issue 😄

fixed in #4443 which'll be in the next release (2.11) since we're already cutting release candidates for 2.10.

authors: bacongobbler jascott1 spothala technosophos

repo: kubernetes/helm


text:
Change the version of echoserver for creating app

I think the yaml file should be changed because of the change of echoserver's version, thank you!

This change is

Coverage remained the same at 43.912% when pulling 343a9f367dcb584d12a422ebaa6a409a009dfc67 on chentao1596:change-echoserver-version into 1a26aa2d5322e5225fedb330aac35af7d0dff7bb on kubernetes:master.

/lgtm

@chentao1596 thanks!

repo: kubernetes/ingress


text:
fix ref to new issue

fix ref to new issue, thank you!

This change is

Coverage increased (+0.02%) to 39.845% when pulling f96e964522c812052fd194eb70180266cb20c03f on chentao1596:fix-ref into e58524f4095d97a8a9100ccf948eeb2a2e7a1d12 on kubernetes:master.

/lgtm


text:
Scale sets on azure

the old kubernetes binaries, used to provision azure with kube.sh created a cluster based on scale sets. Is this going to be a feature with kubernetes-anywhere?
Right now availability sets are provisioned, I reckon this is a bit of work on terraform's side of things. So I was wondering whether this is going to be a feature.

No. For the time being, Kubernetes on Azure will be using AvailabilitySets directly due to some limitations in the VMSS APIs. We are working to bring the relevant APIs to VMSS, at which point in time we will transition back to VMSS.
This is discussed a bit here: https://github.com/colemickens/azure-kubernetes-status#notes
Let me know if that answers your question, or feel free to Close this Issue if it does.

Thanks @colemickens it does answer my question.

Thanks @colemickens it does answer my question.

authors: brunoriscado colemickens

repo: kubernetes/kubernetes-anywhere


text:
Issue with /docs/getting-started-guides/kubeadm/

This is a...

[ ] Feature Request
[x] Bug Report

Problem:
After Exeucting this command
kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address $MASTER_IP
it hangs at the following line
[apiclient] Created API client, waiting for the control plane to become ready
Below are the installed versions !! Is there any issue specific to kubeadm 1.6.1
Setting up kubernetes-cni (0.5.1-00) ...
Setting up socat (1.7.3.1-1) ...
Setting up kubelet (1.6.1-00) ...
Setting up kubectl (1.6.1-00) ...
Setting up kubeadm (1.6.1-00) ...
Setting up ubuntu-fan (0.9.2)
Proposed Solution:
Page to Update:
http://kubernetes.io/...

@vamsijakkula I would recommend seeking help in Kubernetes-users mailing list, IRC or Slack channels. This repository is for documentation issues.

Closing.

authors: ahmetb jaredbhatti vamsijakkula


text:
replace REASON with STATUS

replace REASON with STATUS

This change is

lgtm


text:
Perfdash - e2e metric fix

Correctly merging result of e2e metric with different "contentType" label.

/assign @wojtek-t

/assign @mborsz
Maciek - can you please take a look into it? I don't know anything about perf-dash anyway :)

/lgtm

authors: krzysied mborsz wojtek-t

repo: kubernetes/perf-tests


text:
ja: fix inconsistent translation of "init container"

This is a Bug Report

Problem:
/language ja
I found an inconsistent translation of "init container" in /ja/docs/concepts/workloads/pods/init-containers/ and  /ja/docs/tasks/debug-application-cluster/debug-init-containers/.
On the concept page, it is expressed as "Initコンテナ".
But on the task page, it is expressed as "Init Container".
What do you think about it? Which expression is better or others?
Proposed Solution:
In my opinion just a direct expression "Init Container" is better for the Japanese to understand that it is a term of k8s.
Page to Update:
https://kubernetes.io/ja/docs/concepts/workloads/pods/init-containers/
or
https://kubernetes.io/ja/docs/tasks/debug-application-cluster/debug-init-containers/

/assign

/close

authors: inductor jlandowner

repo: kubernetes/website


text:
Add automated link checking for the k8s website

This is a Feature Request

What would you like to be added

In order to provide more accurate, useful content and to enable more resilient translation workflows, we need to first ensure that links are accurate and unbroken. The best way to do this is through automation (a link checker).

We should:

Update the link checker to build the site with the selected Netlify version

This may imply, as a prerequisite, publishing a container image via automation

Add tooling to run the link checker automatically
Report the results of link checking via GitHub's checks API

We should not (at this stage) fail builds that have broken links.
Why is this needed
Link checking:

reduces review toil
helps reduce or avoid trivial vulnerability reports - see https://github.com/kubernetes/website/issues/32778
improves end user experience

Comments
This follows https://github.com/kubernetes/website/issues/20607
I expect that we'd want to liaise with the SIG Testing people to work out how to get these tests to happen the way we want.
The need for a container image is to avoid doing a new container image build for every new PR. A fresh image per PR doesn't feel like a good fit for the cloud native philosophy.

/assign

The existing script scripts/link_checker.py can be used as a starting point.

/unassign

/triage accepted

authors: ashish-jaiswar reylejano sftim tengqm


text:
Add task for server-side apply

This is a Feature Request

What would you like to be added
Add a companion page to Update API Objects in Place Using kubectl patch that explains how to achieve a similar outcome through Server-Side Apply.
Also update some pages to link to the new page. Here are some pages to update:

https://kubernetes.io/docs/reference/using-api/server-side-apply/
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/
https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources

Why is this needed
Server-side apply is a great way to update things in place, but we're not documenting it as well as we could.
Comments
/language en

/sig api-machinery
/triage accepted

/remove-lifecycle stale

authors: mehabhalodiya sftim vaibhav2107


text:
Update Firewall Topics

This is a...

[x] Feature Request
[ ] Bug Report

Take a look at this topic: Configure Your Cloud Provider's Firewall Rules. Does it belong in the kubernetes.io docs, or should it be in the Google Cloud docs? If you decide to keep it in the kubernetes.io docs, apply the Task template, and edit to comply with our style guide. If possible, make the task into a set of steps that the reader can actually do.

/language en

/priority backlog
Is that OK?

Done
/close


text:
Update Garbage Collection Docs

This is a...

[x] Feature Request
[ ] Bug Report

Take a look at these two topics:

Configuring kubelet Garbage Collection
Garbage Collection

Are they redundant?
Do they belong under Concepts, or could some of this material be a Task?

My feeling is that the two pages should be remixed. We will still need a concept page because most of the garbage collection behavior are not controllable by a user but they need some high-level knowledge about the concept and how GC operations can be indirectly affected. We will need a task page dedicated to operators, for deeper involvement into the GC behavior tuning.
/remove-lifecycle rotten
/lifecycle frozen

/language en

In https://github.com/kubernetes/website/pull/15374#discussion_r303918833, @jaypipes suggests a new page “Understanding object relationships”.
I like that idea so I'm mentioning it here.

@sftim are you interested in spearheading that effort in a new PR? or are you looking for an assist there?

Just wanting to track work that I think is worth doing. I don't particularly plan to pick this up myself.

/priority backlog

/triage accepted
/remove-label team/google

This largely duplicates #4322
/triage duplicate
/remove-triage accepted

/close

authors: jaypipes sftim steveperry-53 tengqm


text:
Fix link to deploy node.js app

Update deploy instructions to link to hello-minikube
node.js app create, deploy.
See issue #10362.

/lgtm
Thanks.

/approve

authors: kbhawkey tengqm zparnold


text:
kubeadm: fix links in kubeadm-alpha page

fixes https://github.com/kubernetes/website/issues/15668
/assign @sftim
/sig cluster-lifecycle
/kind bug
/priority backlog

/retest

the preview CI is not running for some reason.

/lgtm

/LGTM
/approve


text:
trans zh content/zh/docs/reference/access-authn-authz/extensible-admi…

ref:https://github.com/k8smeetup/website-tasks/issues/3683
TLTR
Thanks for your review
/cc @tengqm

/cc @tengqm any advice?

/lgtm
/approve

authors: tanjunchen tengqm


text:
modify layout of codenew shortcode

Update layout of copy-code block within codenew shortcode.
See issue #23020.

Page previews:
https://deploy-preview-23021--kubernetes-io-master-staging.netlify.app/docs/tasks/inject-data-application/define-interdependent-environment-variables/

preview looks good.
LGTM.

/area web-development

/cc @tengqm @sftim

/lgtm

/approve
Thanks @kbhawkey this is clearly better

authors: kbhawkey sftim tengqm


text:
Add WebhookAdmission reference

This adds a reference for WebhookAdmission config generated from kubernetes-sigs/reference-docs/genref tool.
More specifically, it is generated using the following command:
./genref -format markdown -include apiserver-webhookadmission

Preview: https://deploy-preview-26605--kubernetes-io-master-staging.netlify.app/docs/reference/command-line-tools-reference/apiserver-webhookadmission.v1/

/sig api-machinery

/reopen
Oops!

/sig api-machinery

LGTM

/hold
Depends on: https://github.com/kubernetes-sigs/reference-docs/pull/214

/hold cancel
kubernetes-sigs/reference-docs#214 is in.

/lgtm


text:
Replace redirect links of kubeadm

/docs/reference/setup-tools/kubeadm/kubeadm/ is redirected to /docs/reference/setup-tools/kubeadm/.
This replaces the redirect links of kubeadm with the direct links.

/sig cluster-lifecycle


text:
[ko] Update concepts/workloads/controllers

refs #30000 tasks M29-M35

/assign

/lgtm

감사합니다!
/approve

authors: gochist pjhwa seokho-son


text:
add specification uri about Pod

Signed-off-by: song tinysong1226@gmail.com
add specification uri about Pod, like this: https://github.com/kubernetes/website/blob/16e11b248a532681ece92babd36a497a1c5494bf/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md?plain=1#L112

/lgtm
/approve

authors: TinySong tengqm


text:
Updates to Node affinity weight section

Current:
https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity-weight
"If there are two possible nodes that match the requiredDuringSchedulingIgnoredDuringExecution rule, one with the label-1:key-1 label and another with the label-2:key-2 label, the scheduler considers the weight of each node and adds the weight to the other scores for that node, and schedules the Pod onto the node with the highest final score."
Change:
If there are two possible nodes that match the preferredDuringSchedulingIgnoredDuringExecution rule, one with the label-1:key-1 label and another with the label-2:key-2 label, the scheduler considers the weight of each node and adds the weight to the other scores for that node, and schedules the Pod onto the node with the highest final score.

/lgtm
Thanks

authors: balaramvedulla kevin-wangzefeng


text:
[ko] Update outdated files dev-1.24-ko.2 (README-ko.md)

There is an outdated part in README, so I modified it.
This is related to issue #34903.
/language ko

/hold
For a moment,
I am going to request the contributor to change branch. :)

@KimDoubleB 님~~
script를 통해서 추적되지 않는 파일도 추적해서 수정해주셨네요! 감사합니다. :)
(참고로 hold를 남긴 @cat-taesik 은 제 실험용 계정입니다ㅎ)
해당 PR은 base 및 target을 main 브랜치로 해주시면 어떨까 싶습니다. 왜냐하면~ /ko/* 외부에 있는 해당 readme에 한글 승인자가 권한이 없기 때문입니다.
그래서 개발 브랜치를 main에 머지할 때, 영문 리뷰어의 리뷰를 필수로 받아야해서, 개발 브랜치의 스위칭이 다소 늦어질 수가 있습니다.
그래서 매우 예외적으로 해당 작업은 main에서 진행하도록 가이드 드립니다. ;)

@jihoon-seo
상세한 리뷰 감사합니다. 일단은 bash를 제거하도록 하겠습니다. 참고해서 다음 main에 PR을 고려해봐야겠군요.
@seokho-son
확인했습니다. 커밋 이력이 조금 꼬인 것 같아서, 현재 PR은 close 하고 새로운 PR로 진행하겠습니다.

/remove-area blog release-eng
/remove-language de en es fr id it ja pl pt vi zh
/remove-sig release

authors: KimDoubleB cat-taesik jihoon-seo seokho-son


text:
replace newcode to code

replace newcode to code

/lgtm

Thanks @my-git9
/lgtm

/retitle Replace some (deprecated) codenew shortcodes


text:
[zh] Sync feature-gates/g*.md

Related to issue https://github.com/kubernetes/website/issues/44410
Add the new 'stages' metadata to all zh feature gate filename prefixed with "g" in
content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/

gce-regional-persistent-disk.md
generic-ephemeral-volume.md
graceful-node-shutdown-based-on-pod-priority.md
graceful-node-shutdown.md
grpc-container-probe.md

/approve

/lgtm

authors: dipesh-rawat tengqm windsonsea


text:
Reorganize some callouts in etcd admin task

Improve https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

Aim to reduce the large number of note callouts

promote one to a caution.

Preview

/sig etcd


text:
[zh] update dns-debugging-resolution.md

Revise some style issues in:
content/zh-cn/docs/tasks/administer-cluster/dns-debugging-resolution.md

/lgtm
/approve

authors: tengqm windsonsea


text:
Created glossary term for image.

Added new glossary terms for "Image" and "replication controller"

This change is

Adding a comment here as much to remind myself (I hope) to file an issue as anything, since ReplicaSet isn't yet in the glossary. We should cross-reference to it when it shows up, and make it clear that ReplicaSet is now preferred over ReplicationController


text:
Update pull-image-private-registry.md

-d does not work on mac, --decode should work cross platform

/assign @bradtopol

IMO, -d equal to --decode.  Could you paste the output about base64 --help command?

--decode is supported everywhere. Mac is -D not -d
base64 --help
Usage:	base64 [-hvD] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -D, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)

@stewart-yu can you +1?

Have'n use those command cross platform, but if like you say, seems reasonable
/lgtm
/cc @tengqm  @zacharysarah
for approve

We have received similar issue report before. It turned out that neither -d nor -D is portable. So --decode is a safer option.
/lgtm
/approve

authors: samirspatel stewart-yu tengqm


text:
Add necessity of metrics-server for HPA

Current HPA doc1 mentions metrics-server like
For resource metrics, this is the metrics.k8s.io API,
generally provided by metrics-server. It can be launched
as a cluster addon.
The metrics.k8s.io API is mandatory for HPA, so the above means
metrics-server needs to be launched for HPA. However it is difficult
to understand that requirement because the above seems metrics-server
as just a addon, and that is described on small section.
In addition, many people are facing HPA issue that fetching metrics
doesn't work on the internet like
$ kubectl get hpa
NAME      REFERENCE          TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
nginx     Deployment/nginx   /50%   1         3         0          7s
The above sample "" shows HPA feature cannot get current
metrics due to metrics-server doesn't work fine.
This adds necessity of metrics-server for HPA directly to solve
the problem.
fixes: #9728

I added a copyedit.
/approve
/lgtm

@mistyhacks
Thanks for doing that, you make it much better :-)

authors: mistyhacks oomichi


text:
Change "kusk" to Kusk on the Dashboard and CLI

To improve readability within the application use title casing when referring to Kusk.

dashboard: https://github.com/kubeshop/kusk-gateway-dashboard/pull/321

authors: donnalux mortada-codes

repo: kubeshop/kusk-gateway

license: MIT


text:
Create composite GitHub action to simplify workflow configuration

What this PR dose?
Create composite GitHub action to simplify workflow configuration.
Below are input variables' details of composite GitHub action:
  context:
    description: Build context for docker.
    required: true
  dockerfile:
    description: Dockerfile location.
    required: true
  image-name:
    description: Docker image name.
    required: true
  tag-suffix:
    description: Suffix of tag name.
    required: true
    default: ""
  platforms:
    description: Builder node platforms available (comma separated).
    required: true
    default: "linux/amd64"
  build-args:
    description: List of build-time variables.
    required: false
    default: ""
  docker-registry:
    description: Docker registry.
    required: false
    default: docker.io
  docker-namespace:
    description: Docker namespace.
    required: false
    default: ""
  docker-password:
    description: Password of current docker namespace in docker registry.
    required: false
    default: ""
  ghcr-token:
    description: Token of current GitHub account in GitHub container registry.
    required: false
    default: ""

Example of using composite GitHub action:
  BuildBase:
    runs-on: ubuntu-20.04
    steps:
      - uses: actions/checkout@v2
      - name: Build base agent
        uses: ./.github/actions/build
        with:
          context: base
          dockerfile: base/Dockerfile
          image-name: builder-base
          platforms: linux/amd64,linux/arm64
          docker-namespace: ${{ secrets.DOCKER_HUB_USER }}
          docker-password: ${{ secrets.DOCKER_HUB_SECRETS }}
          ghcr-token: ${{ secrets.GHCR_TOKEN }}

For the result, please see:

https://github.com/JohnNiang/devops-agent/actions/runs/1458009939
https://github.com/JohnNiang/devops-agent/actions/runs/1458009940

Why do we need it?
At present, our GitHub workflow configuration is highly repetitive and difficult to manage. If we want to add a new agent into this repo, we need to do some error-prone and duplicate works.
Which issue dose this PR fix?
Fix #53
/kind feature
/cc @kubesphere/sig-devops

/ping @kubesphere/sig-devops

/ping @kubesphere/sig-devops

repo: kubesphere/devops-agent


text:
Bugfix ks 5193

What type of PR is this?
/kind bug
What this PR does / why we need it:
fix bug of the some jenkins configxml overwrite by pipelienrun-controller.
Which issue(s) this PR fixes:

Fixes https://github.com/kubesphere/kubesphere/issues/5193
Special notes for reviewers:

Please check the following list before waiting reviewers:

[ ] Already committed the CRD files to the Helm Chart if you created some new CRDs
[ ] Already added the permission for the new API
[ ] Already added the RBAC markers for the new controllers

Does this PR introduce a user-facing change??

support updatePipelinerunConfigXml in pipelinerun-controller

/lgtm
/approve

fix: https://github.com/kubesphere/kubesphere/issues/5193

repo: kubesphere/ks-devops


text:
Bug 2101445:  Pending changes should not appear if nothing relevant has changed

Signed-off-by: Dana Orr dorr@redhat.com

📝 Description
Pending changes should not appear if nothing relevant has changed.
🎥 Demo
Before:

After:

/lgtm

authors: DanaOrr metalice

repo: kubevirt-ui/kubevirt-plugin


text:
Support control of memory guest overhead with InstanceTypes

Is your feature request related to a problem? Please describe:
Currently it's not possible to control guest overhead with InstanceTypes.
Describe the solution you'd like:
I would like to add fields that allows me to set appropriate QoS class and control the guest overhead. It could be the same as resources.limits.memory and resources.requests.memory fields with appropriate validation against memory.guest.
Describe alternatives you've considered:
Currently I can control it by setting memory options directly in the VM spec but we want to use instance types.
Additional context:
Sometimes we cannot relay on the automatic calculation of memory guest overhead.
That's the same reasoning as described in here: https://github.com/kubevirt/kubevirt/pull/3162

@lyarwood what do you think about this?

From the PR https://github.com/kubevirt/kubevirt/pull/9799 description

The virt-launcher pod will request less physical memory by the OvercommitPercent.

@vladikr what about a use case where we need to request more memory for virt-launcher pod than VM?

/area instancetype
I'd prefer a standalone attribute instead of overloading OvercommitPercent, say a mutually exclusive OverheadRatio attribute so it maps to AdditionalGuestMemoryOverheadRatio?
https://github.com/kubevirt/kubevirt/blob/7c7d8ded67614efc7ca008cbe11102fa9305003c/staging/src/kubevirt.io/api/core/v1/types.go#L2326-L2332

I'd prefer a standalone attribute instead of overloading OvercommitPercent

That makes sense.

say a mutually exclusive OverheadRatio attribute so it maps to AdditionalGuestMemoryOverheadRatio

Sounds good, but AdditionalGuestMemoryOverheadRatio doesn't support values less than 1.0. Meaning you cannot request more memory for pod than VM. Do you want to change this behaviour?

Please correct me if I am wrong, but my understanding is... If we would add `OverheadRatio then we would have:

two ways of achieving guest memory overcommit with OverheadRatio and OvercommitPercent
one way of achieving guest memory "undercommit" with OverheadRatio (and potentially change of AdditionalGuestMemoryOverheadRatio that it accepts values < 1.0)

wouldn't this API be a bit confusing?

Please correct me if I am wrong, but my understanding is... If we would add OverheadRatio then we would have:

two ways of achieving guest memory overcommit with OverheadRatio and OvercommitPercent
one way of achieving guest memory "undercommit" with OverheadRatio (and potentially change of AdditionalGuestMemoryOverheadRatio that it accepts values < 1.0)

wouldn't this API be a bit confusing?

The naming is a little confusing but AdditionalGuestMemoryOverheadRatio actually adds memory to the overall pod resource request and not the memory visible to the guest itself. So values > 1.0 result in undercommit as we are now requesting more memory than visible to the guest.
https://github.com/kubevirt/kubevirt/blob/12321889014f2bd889c85995e4b3107b6348e569/pkg/virt-controller/services/template.go#L1350-L1359
https://github.com/kubevirt/kubevirt/blob/main/pkg/virt-controller/services/renderresources.go#L384-L394
https://github.com/kubevirt/kubevirt/blob/12321889014f2bd889c85995e4b3107b6348e569/pkg/virt-controller/services/renderresources.go#L176-L189

Additionally it would be good if we can over those settings support Guaranteed QoS class as well. The same as when you set resources.memory.limits equal to resources.memory.requests with memory.guest lower than the previous.

Yeah wrapping this stuff in policies would provide a nicer UX but I'd also provide users with the ability to tweak things directly to fit their use case.

The naming is a little confusing but AdditionalGuestMemoryOverheadRatio actually adds memory to the overall pod resource request and not the memory visible to the guest itself. So values > 1.0 result in undercommit as we are now requesting more memory than visible to the guest.

Oh, my bad, thanks!

Yeah wrapping this stuff in policies would provide a nicer UX but I'd also provide users with the ability to tweak things directly to fit their use case.

If we could do this that would be great.

authors: lyarwood mfranczy

repo: kubevirt/kubevirt


text:
[Flaky CI] Kubevirt-io-periodic-link-checker failure (root is not writable according logs)

/kind bug
What happened:
Kubevirt-io-periodic-link-checker fails
https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/logs/kubevirt-io-periodic-link-checker/1314581145471422464
`/` is not writable.
Bundler will use `/tmp/bundler20201009-16-3kuqoq16' as your home directory temporarily.
Fetching source index from https://rubygems.org/
Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Could not fetch specs from https://rubygems.org/

What you expected to happen:
Should pass
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):
Kubernetes version (use kubectl version):
VM or VMI specifications:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/triage build-watcher

/close
@oshoval that belongs to https://github.com/kubevirt/kubevirt.github.io. Would you mind opening an issue there?

/cc @codificat FYI

Thanks @rmohr.
@oshoval I believe this was already fixed and there's no need to open a new issue. Sorry I didn't notice this to close it earlier.

authors: codificat oshoval rmohr


text:
Admit eviction on completed virt-launcher pods

What this PR does
Currently, completed virt-launcher pods can trigger a live migration if an eviction request arrives.
This is wrong since completed pods should be simply evicted.

Fixes #
Release note

Fix: eviction requests to completed virt-launcher pods cannot trigger a live migration

Thank you @orelmisan! Done, PTAL

/cherrypick release-1.3


text:
Move containerdisk script over to golang

What this PR does / why we need it:
First part of reviving #1565. This part moves the bash script to golang code. The second part will add a mount propagation mode which will not require additional privileges on the containerdisk container (in contrast to the solution in #1565.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
NONE

@davidvossel I want to revive your great POC in #1565 with a backward compatible evolution of containerDisks which does not need additional privileges. I think we should make progress and provide a no-copy mode to make this feature production ready.

first off... thank you a million times for converting that horrible bash script to golang.

I want to revive your great POC in #1565 with a backward compatible evolution of containerDisks which does not need additional privileges. I think we should make progress and provide a no-copy mode to make this feature production ready.

yeah absolutely. there's some really interesting possibilities there.

I have two small comments, but except them looks good, the next stage is to move libvirt container scripts to golang

Do you mean like this: https://github.com/kubevirt/kubevirt/pull/1386/commits/6c89d702529dd6abcdaaedb71f1a3c8699d43b63 in #1386? :smile_cat:

/retest

any thoughts on how we can unit test this?

I think we already have tests which rely on qemu-img to be present. should be simple.

Do you mean like this: 6c89d70 in #1386?

I mean this one https://github.com/kubevirt/libvirt/blob/master/libvirtd.sh :smile:

I mean this one https://github.com/kubevirt/libvirt/blob/master/libvirtd.sh

Yes, me too. We don't use it because of #1386. :smile:

/close
I will do one final PR with all changes for containerdisk improvals at once, since it makes this intermediate step useless.

authors: cynepco3hahue davidvossel rmohr


text:
Use a properly SELinux-labelled location for the hostdisk in test 1681

What this PR does / why we need it:
/run/kubevirt-private is labelled container_var_run_t, which containers (labelled container_t) can't write to.
/run/kubevirt is also a tmpfs location, but it has the label we want (container_file_t).
Switching to that.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Should fix at least test 1681 on the 1.17 test lane.
Release note:

NONE

Replaced by https://github.com/kubevirt/kubevirtci/pull/340 and https://github.com/kubevirt/kubevirt/pull/3276


text:
Code Cleanup: Improve gomega matchers in several packages

Change all Expect(len(var)).To(Equal(some-length)) to Expect(var).To(HaveLen(some-length)) in pkg/virt-operator, taging/src/kubevirt.io/client-go/api and pkg/watchdog.
If the expected length is 0, the the new matcher is BeEmpty()
None

/test pull-kubevirt-e2e-k8s-1.22-sig-compute-migrations

/retest

/retest

/test pull-kubevirt-e2e-kind-1.22-sriov

/retest

/test pull-kubevirt-e2e-kind-1.22-sriov


text:
[release-0.58]: Fix: Align Reenlightenment flows between converter.go and template.go

What this PR does / why we need it:
Manual backport for https://github.com/kubevirt/kubevirt/pull/8740.
The reason a manual backport is required is because the functional tests are added to hyperv_test.go which didn't exist in release-58 branch because the PR that created this file wasn't backported.
Release note:

Fix: Align Reenlightenment flows between converter.go and template.go

/cc @vladikr @acardace

/hold
waiting for https://github.com/kubevirt/kubevirt/pull/8793 to get in

/hold cancel

/retest-required

/test pull-kubevirt-build-release-0.58

/test pull-kubevirt-build-0.58

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required


text:
Rename to kubewarden

Also ensure we use the latest release of the Rust SDK

I fixed the clippy warning

repo: kubewarden/psp-capabilities


text:
Copy text from allready existing link

Sometimes I allready have a link to a bibleverse, but I want to copy the text into my note.
It would be very nice to select an existing link, and have it automatically fill that into the dialog of the "copy and link Bible verses command"

Hi, I think this should be possible, but I'm not sure when people would use it. It would require you to have a link that is outside of any other text; otherwise, the copied verses would collide with the text around the link. And if you have a link outside of the other text, why not just copy the verses right away with the command?

repo: kuchejak/obsidian-bible-linker-plugin