Re: openshift/api and openshift/client-go are authoritative
On Tue, 2017-12-05 at 16:25 -0500, Ben Parees wrote: > On Tue, Dec 5, 2017 at 4:13 PM, Simo Sorce wrote: > > > On Tue, 2017-11-28 at 13:58 -0500, David Eads wrote: > > > As of https://github.com/openshift/origin/pull/17477, h > > > ttps://github.com/openshift/api and https://github.com/openshift/ > > > > client-go are > > > the authoritative source of the OpenShift API types and the OpenShift > > > external clients. The external types and go client are no longer present > > > in https://github.com/openshift/origin. This makes it possible to > > > > interact > > > with an OpenShift cluster without trying to vendor openshift/origin and > > > > it > > > changes the way that API changes are merged. > > > > > > To make an API change in 3.8+: > > > > > >1. open a pull with the external types to openshift/api and get it > > >reviewed, approved, and merged > > >2. bump the vendored dependencies in openshift/client-go, regenerate > > >(make generate build), and get it merged. > > >3. bump the vendored dependencies in openshift/origin > > >(hack/update-deps.sh), update your internal types, and start serving > > > > your > > >new API. > > > > > > For forks, you will have to merge into the appropriate branches of the > > > various repositories. > > > > SoI have to deal with this now. > > > > Looking at the api repository I see you opened commits with titles like > > this: > > > > UPSTREAM: openshift/origin: missed tags > > > > I do not understand, if the api repository is authoritative, then this > > repository is upstream, not openshift/origin > > > > Is there a convention we need to follow for the vendoring of api into > > client-go and origin as far as naming commits ? Care to provide an > > example/template ? > > > > "bump(*)" > > I got to be the guinea pig on this, so you can see my prs here: > > changed the api: > https://github.com/openshift/api/pull/10 > > bumped the client-go deps: > https://github.com/openshift/client-go/pull/12 > > trying to bump the origin deps so i can actually make the change i care > about: > https://github.com/openshift/origin/pull/17314/commits/fc47ea3baba0631ba84e82a80a98c10670dabbd8 > I can't think of anything worse than "bump(*)" (or any other fixed strings) to make it so that we have to excavate hashes in the glide files to correlate changes between trees. Can we use a convention where we at least reference the PR in the API/client-go trees ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: openshift/api and openshift/client-go are authoritative
On Tue, 2017-11-28 at 13:58 -0500, David Eads wrote: > As of https://github.com/openshift/origin/pull/17477, h > ttps://github.com/openshift/api and https://github.com/openshift/client-go are > the authoritative source of the OpenShift API types and the OpenShift > external clients. The external types and go client are no longer present > in https://github.com/openshift/origin. This makes it possible to interact > with an OpenShift cluster without trying to vendor openshift/origin and it > changes the way that API changes are merged. > > To make an API change in 3.8+: > >1. open a pull with the external types to openshift/api and get it >reviewed, approved, and merged >2. bump the vendored dependencies in openshift/client-go, regenerate >(make generate build), and get it merged. >3. bump the vendored dependencies in openshift/origin >(hack/update-deps.sh), update your internal types, and start serving your >new API. > > For forks, you will have to merge into the appropriate branches of the > various repositories. SoI have to deal with this now. Looking at the api repository I see you opened commits with titles like this: UPSTREAM: openshift/origin: missed tags I do not understand, if the api repository is authoritative, then this repository is upstream, not openshift/origin Is there a convention we need to follow for the vendoring of api into client-go and origin as far as naming commits ? Care to provide an example/template ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Origin Policies RIP soon
Hello team, We are working hard to move Origin authorization policies over to Kubernetes RBAC in 3.7. We already have a synchronization controller in 3.6 that converts policies to RBAC objects. In 3.7 we are going to stop storing origin policies and only use RBAC objects. Furthermore, we will replace the origin authorizer with k8s authorizer which only respects RBAC objects. This has a few consequences though, and we are seeking some input. Because of the way Origin policies were built we cannot maintain shim APIs for all of them. We have proxy APIs that handle all direct {cluster}role{binding}s APIs, but the APIs that exposed directly the whole policy object are going to disappear (as we do not have such object anymore in the database). In 3.6 we changed all command line tools to use the correct API to deal with roles and bindings so that they won't break once we shut down origin policies for good. However older (< 3.6) clients will fail to perform some operations against a 3.7 cluster due to this change, as some of them used to modify the policy objects directly instead of using the {cluster}role{binding}s APIs. Some of our Ansible tooling targets these endpoints directly as well. Also we'd like to kill or version gate the "oc adm override-policy" command that allows wholesale replacement of policies by directly overwriting ETCD. This command does not make sense in 3.7 as the storage layout is different since we will store many small RBAC objects instead of giant policy objects. Furthermore, a cluster admin can restore access to a server with a broken policy configuration using a cert based user in the "system:masters" group (this group is always allowed to perform any action). Thus that command is not strictly needed any more to fix a cluster and is not useful in most situations. We are seeking input and opinions on how to properly phase out origin policies, our goal is to minimize the amount of code we need to keep around while maintaining the strongest backwards compatibility. Simo & Security Team -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev