profile
viewpoint
Stephen Day stevvooe San Francisco

PR opened cruise-automation/rbacsync

all: update copyright to Cruise LLC

Signed-off-by: Stephen Day stephen.day@getcruise.com

+30 -30

0 comment

27 changed files

pr created time in 15 days

create barnchcruise-automation/rbacsync

branch : update-copyright

created branch time in 15 days

pull request commentcruise-automation/rbacsync

add custom metrics for RBACSync

@mllu thanks for the contribution! Looks pretty good. I have a few nits on naming. Also, let’s have @mattlandis take a peek.

mllu

comment created time in 19 days

Pull request review commentcruise-automation/rbacsync

add custom metrics for RBACSync

+package metrics++import (+	"github.com/prometheus/client_golang/prometheus"+	"github.com/prometheus/client_golang/prometheus/promauto"+)++var (+	// Metrics for Controller+	RBACSyncConfigStatus = promauto.NewGaugeVec(prometheus.GaugeOpts{+		Name: "rbacsync_config_status",+		Help: "The number of RBACSyncConfigs and RBACSyncClusterConfigs and the status of the processed config",+	}, []string{"kind", "status"})+	RBACSyncBindingStatus = promauto.NewGaugeVec(prometheus.GaugeOpts{+		Name: "rbacsync_binding_status",+		Help: "The number of RoleBindings and ClusterRoleBIndings configured by the controller and their statuses",+	}, []string{"kind", "status"})++	// Metrics for Mapper/GSuite+	RBACSyncGsuiteClientCreationStatus = promauto.NewCounter(prometheus.CounterOpts{+		Name: "rbacsync_gsuite_client_creation_status",+		Help: "Total number of the status of gsuite client creations",+	})+	RBACSyncGsuiteMembersStatus = promauto.NewCounterVec(prometheus.CounterOpts{+		Name: "rbacsync_gsuite_members_status",+		Help: "Total number of the status of calls to gsuite with labels for state",+	}, []string{"status"})+	RBACSyncGsuiteMembersLatency = promauto.NewHistogram(prometheus.HistogramOpts{+		Name: "rbacsync_gsuite_members_latency",

Prometheus best practice here would to have this suffixed with duration_seconds.

mllu

comment created time in 19 days

Pull request review commentcruise-automation/rbacsync

add custom metrics for RBACSync

 import ( 	"k8s.io/client-go/tools/cache" 	"k8s.io/client-go/tools/record" 	"k8s.io/client-go/util/workqueue"+	"k8s.io/klog"  	rbacsyncv1alpha "github.com/cruise-automation/rbacsync/pkg/apis/rbacsync/v1alpha" 	clientset "github.com/cruise-automation/rbacsync/pkg/generated/clientset/versioned" 	rbacsyncscheme "github.com/cruise-automation/rbacsync/pkg/generated/clientset/versioned/scheme" 	informers "github.com/cruise-automation/rbacsync/pkg/generated/informers/externalversions/rbacsync/v1alpha" 	listers "github.com/cruise-automation/rbacsync/pkg/generated/listers/rbacsync/v1alpha" 	"github.com/cruise-automation/rbacsync/pkg/groups"+	"github.com/cruise-automation/rbacsync/pkg/metrics" )  const ( 	controllerAgentName = "rbacsync" ) +const (+	MetricsRBACSyncConfig        = "RBACSyncConfig"+	MetricsRBACSyncClusterConfig = "RBACSyncClusterConfig"

Could you make this consistent with the other references? ClusterRBACSyncConfig is what I think we use.

mllu

comment created time in 19 days

Pull request review commentkubernetes/kubernetes

Don't leak a go routine on panic

 func (t *timeoutHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { 	case <-after: 		postTimeoutFn() 		tw.timeout(err)++		// resultCh needs to have a reader, since the function doing+		// the work needs to send to it.+		go func() {+			res := <-resultCh

One more possible approach: try to send in the defer, fail if the listener is gone and print the utilruntime.HandleError(t) if that fails:

select {
case resultCh <- err:
default:
  utilruntime.HandleError(err)
}
lavalamp

comment created time in a month

Pull request review commentkubernetes/kubernetes

Don't leak a go routine on panic

 func (t *timeoutHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { 	case <-after: 		postTimeoutFn() 		tw.timeout(err)++		// resultCh needs to have a reader, since the function doing+		// the work needs to send to it.+		go func() {+			res := <-resultCh

Ok, I see. You want a panic or a stack trace if the goroutine returns later.

lavalamp

comment created time in a month

Pull request review commentkubernetes/kubernetes

Don't leak a go routine on panic

 func (t *timeoutHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { 	case <-after: 		postTimeoutFn() 		tw.timeout(err)++		// resultCh needs to have a reader, since the function doing+		// the work needs to send to it.+		go func() {+			res := <-resultCh

Does this need to be non-blocking? For example, res, ok := <-resultCh.

The other thing that could be done here is to have the channel be buffered to a length of 1. That way, the writer just writes and goes away if it returns and you don't need this extra goroutine.

lavalamp

comment created time in a month

startedkubernetes/kubernetes

started time in 2 months

issue commentopencontainers/artifacts

Clarification: manifest.config.mediaType defines artifact types

I think this encodes what we intend. At minimum, a mediaType must encode the representation of the artifact (json, protobuf, encryption, compression, etc.). We should call out that this is a many to one relationship, in that you might have multiple mediaTypes representing the same content or similarly encoded content, but their handling may differ due to the mediaType. One example is the docker and oci mediatypes for indexes. They are identical formats, handling and meaning but have different mediaTypes. Another, contrived example, might be a format that uses regular OCI layers, compatible in format, but are interpreted differently by the format.

SteveLasker

comment created time in 2 months

startedmoul/protoc-gen-gotemplate

started time in 2 months

pull request commentcontainerd/ttrpc

Client.Call(): do not return error if no Status is set (gRPC v1.23 and up)

This doesn’t seem right. How is it a part of a cve?

thaJeztah

comment created time in 3 months

Pull request review commentopencontainers/artifacts

Collection of definitions and terms

+# Definitions and Terms++A collection of definitions and terms used within this repository.++* [Artifact Author](#artifact-author)+* [Distribution Operator](#distribution-operator)+* [Media Type](#media-type)+* [OCI Image](#oci-image)+* [Registry](#registry)+* [YASS](#yass)++## Artifact Author++The owner of an artifact format. The [OCI Image Spec](https://github.com/opencontainers/image-spec/) is owned by the OCI working group. ++An artifact is defined to be unique by it's `config.mediaType`. ++## Container Registry++See [Registry](#registry)+++## Distribution Operator++Vendors that implement and/or run the [OCI Distribution Spec](https://github.com/opencontainers/distribution-spec/). ++## Media Type++The uniqueness of an artifact is defined by it's type. An artifact has a type, which has a collection of layers.
The uniqueness of an artifact is defined by its type. An artifact has a type, which has a collection of layers.
SteveLasker

comment created time in 3 months

Pull request review commentopencontainers/artifacts

Collection of definitions and terms

+# Definitions and Terms++A collection of definitions and terms used within this repository.++* [Artifact Author](#artifact-author)+* [Distribution Operator](#distribution-operator)+* [Media Type](#media-type)+* [OCI Image](#oci-image)+* [Registry](#registry)+* [YASS](#yass)++## Artifact Author++The owner of an artifact format. The [OCI Image Spec](https://github.com/opencontainers/image-spec/) is owned by the OCI working group. ++An artifact is defined to be unique by it's `config.mediaType`. 
An artifact is defined to be unique by its `config.mediaType`. 
SteveLasker

comment created time in 3 months

Pull request review commentopencontainers/tob

Add artifacts proposal

+# OCI Artifacts Project Proposal++## Abstract++Container registries, implementing the [OCI distribution-spec][distribution-spec], provide reliable, highly scalable, secured storage services for container images. Customers use cloud provider implementations, vendor implementations, and instances of the open source implementation of docker distribution. They configure security and networking to assure the images in the registry are locked down and accessible by the resources required. Cloud providers and vendors often provide additional value atop their registry implementations from security to productivity features. ++Applications and services typically require additional artifacts to deploy and manage container images, including [helm](https://helm.sh) charts for deployment and [Open Policy Agent (OPA) bundles](https://github.com/open-policy-agent/opa/issues/1413) for policy enforcement.++Utilizing the [OCI manifest][image-manifest] and [OCI index][image-index] definitions, new artifact types can be stored and served using the [OCI distribution-spec][distribution-spec] without changing the actual distribution spec. This repository will provide a reference for artifact authors and registry implementors for supporting these new artifact types themselves with the existing implementations of distribution.++By providing support for OCI artifact types over OCI distributions, the community can continue to innovate, focusing on new artifact types without having to build yet another storage solution (YASS). ++## Proposal++Under the [github.com/opencontainers](http://github.com/opencontainers) organization:++- Create a new **artifacts** repository, named [github.com/opencontainers/artifacts](http://github.com/opencontainers/artifacts)+- Update the [OCI distribution-spec][distribution-spec] to generically reference [OCI manifest][image-manifest] and [OCI index][image-index], with [OCI Image][image-spec] as one of many artifact types it can store. +- Update the [OCI image-spec][image-spec] to reference images as an implementation of artifacts, using [OCI manifest][image-manifest] and [OCI index][image-index]++## Contents++The repository will serve 3 primary goals:++1. **artifact authors** - guidance for authoring new artifact types. Including a clearing house for well known artifact types.+1. **registry operators and vendors** - guidance for how operators and vendors can support new artifact types, including how they can opt-in or out of well known artifact types. Registry operators that already implement `media-type` filtering will not have to change. The artifact repo will provide context on how new `media-type`s can be used, and how `media-type`s can be associated with a type of artifact. +1. **clearing house for well known artifacts** - artifact authors can submit their artifact definitions, providing registry operators a list by which they can easily support. ++### Process for Approving New Artifact Definitions++1. Proposals for new artifact types should be opened as pull requests on the artifact repository+1. The artifact project maintainers will review new proposals, ask clarifying questions, and choose or not to accept the suggested artifact type+1. Acceptance requires at least 2 +1s from the maintainers (currently 3 maintainers)+1. Where the submitter disagrees strongly with the decision they can bring to the issue to the TOB for a vote, under the current voting rules.++### Initial Maintainers++Initial maintainers of the artifacts project would be :++- Steve Lasker <steve.lasker@microsoft.com> (@stevelasker)+- Derek McGowan <derek.mcgowan@docker.com> @derekmcgowan+- Mike Brown <brownwm@us.ibm.com> @mikebrow

Do you want me to help? ;)

SteveLasker

comment created time in 3 months

more