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
