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, 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 > > 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 > -- Ben Parees | OpenShift ___ 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
