SIG Scalability Charter #2149

wojtek-t · 2018-05-14T12:53:22Z

@kubernetes/sig-scalability-api-reviews
@countspongebob @shyamjvs @wasylkowski-a @gmarek

cc-ing everyone who was on the initial version:
/cc @thockin @smarterclayton @spiffxp @jdumars @bgrant0607 @timothysc

wasylkowski-a · 2018-05-18T09:19:41Z

sig-scalability/charter.md

+- An initial set of technical leads was set to long-standing group of SIG leads:
+  Wojciech Tyczynski and Bob Wise
+- Technical leads must have demonstrated deep understanding of the whole system
+  that is sufficient to access impact of different changes on Kubernetes scalability.


s/access/assess

wasylkowski-a · 2018-05-18T09:19:55Z

sig-scalability/charter.md

+- Number: 2-3
+- Run operations and processes governing the SIG
+- A majority of chairs cannot be from a single company.
+- An initial set of chairs was established at the time the SIG was founded.


Who are the initial chairs?

Bob Wise and myself

Can you put it into the charter given that you have put TLs' names?

countspongebob · 2018-06-28T17:14:35Z

/approve

wojtek-t · 2018-06-29T09:22:43Z

@thockin @smarterclayton @bgrant0607 @spiffxp - can you please take a look?
Is there any official procedure to have the charter approved?

jdumars · 2018-06-29T18:16:11Z

This is in the Steering Committee backlog under: kubernetes/steering#31

philips

Overall looks OK but could do with some more contextual linking and information as commented.

philips · 2018-07-03T00:25:53Z

sig-scalability/charter.md

+single place of Kubernetes may affect the whole system. As a result, to
+effectively ensure Kubernetes scales, we need a special cross-SIG privileges.
+
+- We can rollback any merged PR if it has been identified as a cause of an SLO


can you link to the SLOs? Where are they? Who defines them? Is the API machinery one below the only example?

Linked (that answers where they are).

Who defines them: sig-scalability with cooperation of sigs that these SLIs/SLOs are touching.

Re API-machinery one - yes (though it was reoriganized recently so updated the links).

philips · 2018-07-03T00:26:11Z

sig-scalability/charter.md

+  <td>Cluster loader</td>
+</tr>
+<tr>
+  <td>Scalability and performanc tests</td>


perfomanc spelling error

philips · 2018-07-03T00:28:12Z

sig-scalability/charter.md

+  TODO(wojtek-t, shyamjvs): Write it down and link here.
+- We require significant changes (in terms of impact, such as: update of etcd,
+  update of Go version, major architectural changes, etc.) may only be merged:
+  - with an explicit approval from a SIG-scalability approver and


where are the approvers documented?

Added subsection in the roles section.

philips · 2018-07-03T00:28:58Z

sig-scalability/charter.md

+<tr>
+  <td>Subproject</td>
+  <td>Description</td>
+  <td>Example Artifacts</td>


Can this table have a column for a link to the OWNERS file? It requires a bit of digging for each of these.

Done (modulo one line, which I would like to figure out independently in parallel - hopefully that doesn't block charter).

wojtek-t

PTAL

wojtek-t · 2018-08-27T08:35:03Z

sig-scalability/charter.md

+## Scope
+
+SIG Scalability primary responsibilities are to define scalability goals for
+Kubernetes, define, test and measure performance and scalability related


Thanks for suggestion - done.

wojtek-t · 2018-08-27T08:49:01Z

sig-scalability/charter.md

+
+[performance/scalability SLOs]: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md
+
+### SIG Scalability approvers


So I thought a bit more about that, and:

longer term it may make sense to move to sigs.yaml

currently, it's not supported there (it's somewhat sig-specific role) and i don't want to add that now.

spiffxp

Thanks for working on this. There are a couple of areas I would like to see some more explicit definition of scope. I may not have time to review the next iteration until Thursday.

spiffxp · 2018-08-27T18:40:17Z

sig-scalability/charter.md

+
+[performance/scalability SLOs]: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md
+
+### SIG Scalability approvers


This sounds like you're listing Tech Leads, which yes, should be in sigs.yaml, and is supported as leadership.tech_leads

If you're trying to define a decision making process (ie: at least 3 of these must approve, any one of these has the authority to approve, etc) I would instead put this under a Technical Processes header, and add boilerplate about how you're overriding sig-governance in the following ways...

spiffxp · 2018-08-27T18:48:32Z

sig-scalability/charter.md

+
+## Scope
+
+SIG Scalability primary responsibilities are to define scalability goals for


Nit: SIG Scalability's

to define and drive scalability goals

spiffxp · 2018-08-27T18:56:35Z

sig-scalability/charter.md

+
+SIG Scalability primary responsibilities are to define scalability goals for
+Kubernetes. This involves defining, testing and measuring performance and
+scalability related to Service Level Indicators (SLIs) and ensure that every


nit: s/to//

nit: s/ensure/ensuring/

spiffxp · 2018-08-27T18:56:43Z

sig-scalability/charter.md

+SIG Scalability primary responsibilities are to define scalability goals for
+Kubernetes. This involves defining, testing and measuring performance and
+scalability related to Service Level Indicators (SLIs) and ensure that every
+Kubernetes release meets Service Level Objectives (SLOs) build on top of those


s/build/built

I would tighten this statement up a bit. By saying "release" this implies you're only enforcing Kubernetes releases meet these SLOs, and that it is OK for alphas, betas, rcs, and other builds to fail to meet them. Your processes below make me think this is not the case.

I don't fully agree. What we really care is that the release that our users use in production (I really doubt someone is using alpha or beta cut in production) meet scalability needs.
So in theory I would say it's fine if those doesn't meet SLOs.
In practise, it's hard to do stuff and only then see if we didn't regress. So we're trying to ensure that those are met all the time (though we are not there yet).

But this is "implementation detail of the strategy", not something that should be part of the charter in my opinion.

spiffxp · 2018-08-27T20:29:06Z

sig-scalability/charter.md

+## Scope
+
+SIG Scalability primary responsibilities are to define scalability goals for
+Kubernetes. This involves defining, testing and measuring performance and


Can more concretely define which parts of Kubernetes you're setting scalability goals for? It might help to refer to the architecture roadmap eg:

On one extreme, you probably don't intend to have purview over the scalability goals of everything in the entire Kubernetes project (which I define as all repos in kubernetes, kubernetes-sigs, kubernetes-client, etc)

On the other extreme, you probably have purview over more than just the contents of kubernetes/kubernetes (and even within this, you probably don't have purview over all of the addons contained within)

You probably don't mean scalability of the project itself, since that falls under contributor experience and to some degree architecture

Another way to consider this: what plugins, runtimes, hardware, workloads, etc. result in a cluster not being held to scalability SLO's?

It may be worth considering taking an approach similar to SIG Instrumentation, another horizontal SIG with some areas of discrete ownership:

Own performance and scalability best practices for the project as a whole

Provide reviews, and guidance to other SIGs

Own the definition, implementation, and enforcement of scalability SLIs and SLOs for the artifacts produced as part of a Kubernetes release

spiffxp · 2018-08-27T21:34:04Z

sig-scalability/charter.md

+
+- We can rollback any merged PR if it has been identified as a cause of any
+  [performance/scalability SLOs] regression. The offending PR should only be
+  merged again after proving to pass  tests at scale.


We don't necessarily have to do this within this charter, but I'm going to suggest that the release team require regular participation from a member of SIG Scalability until we have such automation in place. Chasing down scalability related failures is too much an additional burden on the CI Signal role, and we often have little visibility into whether or how failures are being worked.

As an example both https://k8s-testgrid.appspot.com/sig-scalability-gce#gce-scale-performance and https://k8s-testgrid.appspot.com/sig-scalability-gce#gce-scale-correctness have been failing for over two weeks. This is being "explained away" as a quota issue, with code continuing to merge, rather than being enforced as a hard stop until the cause is identified.

spiffxp · 2018-08-27T21:37:50Z

sig-scalability/charter.md

+  TODO(wojtek-t, shyamjvs): Write it down and link here.
+- We require significant changes (in terms of impact, such as: update of etcd,
+  update of Go version, major architectural changes, etc.) may only be merged:
+  - with an explicit approval from a [SIG-scalability approver](#sig-scalability-approvers)


It shouldn't be tech lead - it's a much wider role and this group may involve other people not necessary being members of sig scalability.

But I'm tired explaining this over and over again, so I'm changing this to tech leads with a TODO for the future.

spiffxp · 2018-08-27T21:40:32Z

sig-scalability/charter.md

+  update of Go version, major architectural changes, etc.) may only be merged:
+  - with an explicit approval from a [SIG-scalability approver](#sig-scalability-approvers)
+    and
+  - after having passed performance testing on biggest supported clusters (unless


In a future where there are large cluster jobs being run on multiple cloud providers, will you require that they all pass?

How does someone run these jobs as a presubmit?

In a future where there are large cluster jobs being run on multiple cloud providers, will you require that they all pass?

If they will be added as release blockers - then yes.

How does someone run these jobs as a presubmit?

They are already optional presubmits that one can manually trigger.
But this is technical detail - such things shouldn't be part of charter.

spiffxp · 2018-08-27T21:42:34Z

sig-scalability/charter.md

+  causes a significant degradation of overall Kubernetes scalability/performance.
+  (Ideally it would be “SLI degradation of more than X%” or “breaking SLO”, but
+  initially it may also be SIG-scalability decision based on public test results).
+- We can block a feature from transitioning to GA status if it cannot be used at


How is this different than the requirements spelled out for beta status? I'd like to see this phrased in terms of SLI/SLO

I think it was clear than it apparently is. The overall idea is:

Alpha->Beta: this can't break existing SLOs (but feature itself doesn't need to scale well)
[As an example: we used to have a store with pod anti-affinity that even if it wasn't used, it was completely breaking scheduling throughput. That's not acceptable.]

Beta->GA: feature itself has to scale.
This may (in rare cases) require introducing a new SLI/SLO to verify that, but in majority just using that feature in our scalability tests and verifying that already existing SLOs are met.

Rephrased to better match what i wrote above.

spiffxp · 2018-08-27T21:45:02Z

sig-scalability/charter.md

+    and
+  - after having passed performance testing on biggest supported clusters (unless
+    found unnecessary by scalability approver)
+- We can block a feature from transitioning to Beta status if (when turned on) it


I really like this idea. But, you might want to consider rephrasing it such that SIG Architecture actually owns this enforcement, and you are in charge of defining the scalability SLI's/SLO's that they use. Ultimately I think it's going to be less confusing for feature owners to look to a single SIG for go/no-go, and use a checklist of requirements you've helped write.

Well - it's definitely not a goal to have a dedicated SLO for every single feature. That doesn't scale and such a huge list of SLIs would be impossible to track especially for users.

About moving the responsibility to sig architecture: TBH I don't really understand your point. SIG architecture is NOT stamping every single transition between phases for every single feature from what I know.
Assuming that I'm not missing anything here, the point of moving the responsibility to sig architecture doesn't make sense because ultimately it would be us saying sig architecture if they say yes or no. That doesn't make sense to me.

wojtek-t

PTAL

wojtek-t · 2018-08-28T06:23:49Z

sig-scalability/charter.md

+
+## Scope
+
+SIG Scalability primary responsibilities are to define scalability goals for


wojtek-t · 2018-08-28T06:25:55Z

sig-scalability/charter.md

+
+SIG Scalability primary responsibilities are to define scalability goals for
+Kubernetes. This involves defining, testing and measuring performance and
+scalability related to Service Level Indicators (SLIs) and ensure that every


wojtek-t · 2018-08-28T06:30:01Z

sig-scalability/charter.md

+SIG Scalability primary responsibilities are to define scalability goals for
+Kubernetes. This involves defining, testing and measuring performance and
+scalability related to Service Level Indicators (SLIs) and ensure that every
+Kubernetes release meets Service Level Objectives (SLOs) build on top of those


I don't fully agree. What we really care is that the release that our users use in production (I really doubt someone is using alpha or beta cut in production) meet scalability needs.
So in theory I would say it's fine if those doesn't meet SLOs.
In practise, it's hard to do stuff and only then see if we didn't regress. So we're trying to ensure that those are met all the time (though we are not there yet).

But this is "implementation detail of the strategy", not something that should be part of the charter in my opinion.

wojtek-t · 2018-08-28T06:31:39Z

sig-scalability/charter.md

+  - [Cluster loader](https://github.com/kubernetes/perf-tests/tree/master/clusterloader2)
+  - [Kubemark](https://github.com/kubernetes/kubernetes/tree/master/cmd/kubemark)
+- Scalability and performance tests:
+  - [Tests](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/scalability/)


wojtek-t · 2018-08-28T06:31:52Z

sig-scalability/charter.md

+  - [Kubemark](https://github.com/kubernetes/kubernetes/tree/master/cmd/kubemark)
+- Scalability and performance tests:
+  - [Tests](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/scalability/)
+


Other than kubemark and tests themselves, no.

wojtek-t · 2018-08-28T06:38:34Z

sig-scalability/charter.md

+  TODO(wojtek-t, shyamjvs): Write it down and link here.
+- We require significant changes (in terms of impact, such as: update of etcd,
+  update of Go version, major architectural changes, etc.) may only be merged:
+  - with an explicit approval from a [SIG-scalability approver](#sig-scalability-approvers)


It shouldn't be tech lead - it's a much wider role and this group may involve other people not necessary being members of sig scalability.

But I'm tired explaining this over and over again, so I'm changing this to tech leads with a TODO for the future.

wojtek-t · 2018-08-28T06:41:58Z

sig-scalability/charter.md

+  update of Go version, major architectural changes, etc.) may only be merged:
+  - with an explicit approval from a [SIG-scalability approver](#sig-scalability-approvers)
+    and
+  - after having passed performance testing on biggest supported clusters (unless


In a future where there are large cluster jobs being run on multiple cloud providers, will you require that they all pass?

If they will be added as release blockers - then yes.

How does someone run these jobs as a presubmit?

They are already optional presubmits that one can manually trigger.
But this is technical detail - such things shouldn't be part of charter.

wojtek-t · 2018-08-28T06:52:33Z

sig-scalability/charter.md

+    and
+  - after having passed performance testing on biggest supported clusters (unless
+    found unnecessary by scalability approver)
+- We can block a feature from transitioning to Beta status if (when turned on) it


Well - it's definitely not a goal to have a dedicated SLO for every single feature. That doesn't scale and such a huge list of SLIs would be impossible to track especially for users.

About moving the responsibility to sig architecture: TBH I don't really understand your point. SIG architecture is NOT stamping every single transition between phases for every single feature from what I know.
Assuming that I'm not missing anything here, the point of moving the responsibility to sig architecture doesn't make sense because ultimately it would be us saying sig architecture if they say yes or no. That doesn't make sense to me.

wojtek-t · 2018-08-28T06:55:28Z

sig-scalability/charter.md

+  causes a significant degradation of overall Kubernetes scalability/performance.
+  (Ideally it would be “SLI degradation of more than X%” or “breaking SLO”, but
+  initially it may also be SIG-scalability decision based on public test results).
+- We can block a feature from transitioning to GA status if it cannot be used at


I think it was clear than it apparently is. The overall idea is:

Alpha->Beta: this can't break existing SLOs (but feature itself doesn't need to scale well)
[As an example: we used to have a store with pod anti-affinity that even if it wasn't used, it was completely breaking scheduling throughput. That's not acceptable.]

Beta->GA: feature itself has to scale.
This may (in rare cases) require introducing a new SLI/SLO to verify that, but in majority just using that feature in our scalability tests and verifying that already existing SLOs are met.

Rephrased to better match what i wrote above.

wojtek-t · 2018-08-28T07:01:12Z

sig-scalability/charter.md

+
+[performance/scalability SLOs]: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md
+
+### SIG Scalability approvers


I gave up for now and switched to tech leads with a TODO to create a dedicated group for it.

timothysc

I think fixup the TODOs and minor wording order, then LGTM.

timothysc · 2018-08-28T19:10:28Z

sig-scalability/charter.md

+	identified and mitigated.
+  The “Rules of engagement” of pausing merge-queue and rationale for
+  necessity of its introduce are explained in a separate doc. <br/>
+  TODO(wojtek-t, shyamjvs): Write it down and link here.


timothysc · 2018-08-28T19:11:42Z

sig-scalability/charter.md

+- We can require a SIG to introduce a regression-catching benchmark test for a
+  scalability-critical functionality.
+
+For the record, by regression above we mean a regression identified by the set 


might just want to define taxonomy at the beginning or end, this seems weirdly placed. Could just remove.

wojtek-t · 2018-08-29T10:15:02Z

PTAL

timothysc

One thing then LGTM

timothysc · 2018-08-29T14:28:19Z

sig-scalability/charter.md

+  - with an explicit approval from a SIG-scalability tech lead and
+  - after having passed performance testing on biggest supported clusters (unless
+    found unnecessary by approver)
+  TODO(wojtek-t): Create a larger group (whose members doesn't have to necessary


TODO - still exists.

I don't want to resolve it now - this is a bigger thing and for now I think it's fine to start with tech leads.

I'd just remove that sentence then, and PR the charter at a later time when TODO is less ambiguous.

Make sense - done.

philips · 2018-08-29T17:12:44Z

sig-scalability/block_merges.md

+- Mitigate the regression. This may mean e.g.:
+  - reverting the PR
+  - switching a feature off (preferably by default, as last resort only in tests)
+  - ...


Please remove this .... It doesn't add anything to the list.

fair enough - done.

wojtek-t

Thanks for comments - PTAL

wojtek-t · 2018-08-30T06:41:16Z

sig-scalability/block_merges.md

+- Mitigate the regression. This may mean e.g.:
+  - reverting the PR
+  - switching a feature off (preferably by default, as last resort only in tests)
+  - ...


fair enough - done.

wojtek-t · 2018-08-30T06:41:50Z

sig-scalability/charter.md

+  - with an explicit approval from a SIG-scalability tech lead and
+  - after having passed performance testing on biggest supported clusters (unless
+    found unnecessary by approver)
+  TODO(wojtek-t): Create a larger group (whose members doesn't have to necessary


Make sense - done.

timothysc

/lgtm
/approve

@wojtek-t thank you for seeing this through!

k8s-ci-robot · 2018-08-31T17:49:43Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: countspongebob, timothysc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~sig-scalability/OWNERS~~ [countspongebob,timothysc]

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

out-of-date

spiffxp

@timothysc I do not appreciate that this was merged without me having gotten another pass at it. @wojtek-t reached out to me privately asking for another look, which I was in the middle of doing when this was merged.

There a few things that need to be followed up on

spiffxp · 2018-08-31T18:27:56Z

sig-scalability/charter.md

+  [performance/scalability SLOs] regression (identified by the set of release
+  blocking scalability/performance tests). The offending PR should only be
+  merged again after proving to pass  tests at scale.
+- In the even of a performance regression, we can block all PRs from being


Fixed in #2617 (thanks)

spiffxp · 2018-08-31T18:28:26Z

sig-scalability/charter.md

+  merged again after proving to pass  tests at scale.
+- In the even of a performance regression, we can block all PRs from being
+  merged into the relevant repos until the cause of the regression is
+	identified and mitigated.


nit: whitespace

Fixed in #2617 - thanks

spiffxp · 2018-08-31T18:30:40Z

sig-scalability/charter.md

+  necessity of its introduce are explained in [a separate doc](./block_merges.md).
+- We require significant changes (in terms of impact, such as: update of etcd,
+  update of Go version, major architectural changes, etc.) may only be merged:
+  - with an explicit approval from a SIG-scalability tech lead and


I don't see your tech leads in sigs.yaml

Adding now. Following up on that - expect a PR in the next few days.

spiffxp · 2018-08-31T18:32:14Z

sig-scalability/block_merges.md

+### Rules of engagement.
+The rules of engagement for blocking merges are as following:
+
+- Observe as scalability regression on one of release-blocking test suites.


Which suites specifically?

How is a regression observed? The suites have been continually failing, so it doesn't seem like it's a green-to-red transition.

It's "green-red transition".
The fact that tests are red now and it's not possible, shouldn simply mean that we don't have the right.
We need to transition from green to red to declare a regression.

Clarifying that.

spiffxp · 2018-08-31T18:32:42Z

sig-scalability/block_merges.md

+  - reverting the PR
+  - switching a feature off (preferably by default, as last resort only in tests)
+  - fixing the problem (if it's easy and quick to fix)
+- Unblock PR merged.


nit: "Unblock merges of all PRs to the relevant repos"

send out a PR with that.

spiffxp · 2018-08-31T18:33:25Z

sig-scalability/block_merges.md

+The rules of engagement for blocking merges are as following:
+
+- Observe as scalability regression on one of release-blocking test suites.
+- Block merges of all PRs.


Block merges of all PRs to the relevant repos, declaring which repos those are and why

send out a PR with that

spiffxp · 2018-08-31T18:33:51Z

sig-scalability/block_merges.md

+  - fixing the problem (if it's easy and quick to fix)
+- Unblock PR merged.
+
+The exact technical mechanisms for it are out of scope for this document.


If not here then where are these mechanisms documented?

This should be hidden in the test-infrastructure (in the past we were talking about opening a bug that is appropriate labeled that merge-bot is looking into). But no matter what the mechanism will be, this is implementation detail and shouldn't be part of this high-level doc.

spiffxp · 2018-08-31T18:34:38Z

sig-scalability/block_merges.md

+  - once a regression is merged, and no other action is taken, it is only
+    a matter of time until another regression is merged on top of it,
+  - debugging the cause of two simultaneous (piled-up) regressions is 
+    exponentially harder, see issue 53255 which links to past experience


nit: link to kubernetes/kubernetes#53255

send out a PR for that

spiffxp · 2018-08-31T18:35:23Z

sig-scalability/block_merges.md

+    a matter of time until another regression is merged on top of it,
+  - debugging the cause of two simultaneous (piled-up) regressions is 
+    exponentially harder, see issue 53255 which links to past experience
+- we need to keep flakiness of merge-blocking jobs very low:


what is the threshold? I suspect we are not meeting this today, so I would like to quantify how we're approaching this delta from actual to intended

spiffxp · 2018-08-31T18:55:56Z

@timothysc Next time please give a last call ping prior to merging

k8s-ci-robot requested review from bgrant0607, jdumars, smarterclayton, spiffxp, thockin and timothysc May 14, 2018 12:53

This was referenced May 14, 2018

SIG-scalability charter. #1829

Closed

SIG-scalability charter. #1607

Closed

wasylkowski-a reviewed May 18, 2018

View reviewed changes

wojtek-t force-pushed the sig_scalability_charter branch from 18826ab to 786f992 Compare May 18, 2018 09:43

pwittrock added the committee/steering Denotes an issue or PR intended to be handled by the steering committee. label Jun 21, 2018

jdumars mentioned this pull request Jun 24, 2018

Charters Meta-issue kubernetes/steering#31

Closed

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 28, 2018

philips previously requested changes Jul 3, 2018

View reviewed changes

wojtek-t force-pushed the sig_scalability_charter branch 8 times, most recently from 33a545a to dfc57ed Compare July 3, 2018 09:28

k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 24, 2018

SIG Scalability Charter

cc370d2

wojtek-t force-pushed the sig_scalability_charter branch from 95a5f64 to 8b24001 Compare August 27, 2018 08:49

wojtek-t commented Aug 27, 2018

View reviewed changes

spiffxp previously requested changes Aug 27, 2018

View reviewed changes

wojtek-t force-pushed the sig_scalability_charter branch from 8b24001 to f9777ff Compare August 28, 2018 07:00

wojtek-t commented Aug 28, 2018

View reviewed changes

timothysc reviewed Aug 28, 2018

View reviewed changes

wojtek-t force-pushed the sig_scalability_charter branch from f9777ff to e2e2569 Compare August 29, 2018 10:13

timothysc reviewed Aug 29, 2018

View reviewed changes

philips reviewed Aug 29, 2018

View reviewed changes

Apply template

b6ea653

wojtek-t force-pushed the sig_scalability_charter branch from e2e2569 to b6ea653 Compare August 30, 2018 06:42

wojtek-t commented Aug 30, 2018

View reviewed changes

k8s-ci-robot assigned timothysc Aug 31, 2018

timothysc approved these changes Aug 31, 2018

View reviewed changes

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 31, 2018

timothysc removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API labels Aug 31, 2018

k8s-ci-robot merged commit 55d3d7c into kubernetes:master Aug 31, 2018

spiffxp reviewed Aug 31, 2018

View reviewed changes

spiffxp mentioned this pull request Aug 31, 2018

sig-scalability needs to declare tech leads in sigs.yaml #2616

Closed

spiffxp mentioned this pull request Aug 31, 2018

Fix scalability charter typos #2617

Merged

wojtek-t deleted the sig_scalability_charter branch January 3, 2019 11:52

wojtek-t mentioned this pull request Feb 17, 2022

KEP-3138: Increase the Reliability Bar proposal kubernetes/enhancements#3139

Closed


		[performance/scalability SLOs]: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md

		### SIG Scalability approvers


		## Scope

		SIG Scalability primary responsibilities are to define scalability goals for

SIG Scalability Charter #2149

SIG Scalability Charter #2149

Conversation

wojtek-t commented May 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

countspongebob commented Jun 28, 2018

wojtek-t commented Jun 29, 2018

jdumars commented Jun 29, 2018

philips left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wojtek-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spiffxp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wojtek-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timothysc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wojtek-t commented Aug 29, 2018

timothysc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wojtek-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timothysc left a comment