> > Yup, thanks, that doc definitely needs to be fixed. Adam can you make > sure that happens? (Along w/ fixing the api doc) >
Bug has been filed against our 3.11 docs: https://bugzilla.redhat.com/show_bug.cgi?id=1693685 On Thu, Mar 28, 2019 at 9:01 AM Ben Parees <bpar...@redhat.com> wrote: > > > On Thu, Mar 28, 2019 at 6:48 AM Andrew Feller <afel...@bandwidth.com> > wrote: > >> Thanks for the follow up, Ben. >> >> I suppose we haven't created any new BuildConfigs from scratch since our >> v3.9 => v3.11 upgrade, however there is no mention within OCP 3.11 >> release notes >> <https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html> >> about >> this change of behavior >> > > We introduced this new behavior when we introduced the groupified apis, i > think that was before 3.11. But I can't guarantee it made the release > notes for whatever release it was done in. > > I suspect what happened here though is that you are defining your > buildconfigs using the legacy apiversion and, up until 3.11, that meant > your oc creates went through the legacy api. In 3.11 (I think) changes > were made that sent all api calls through the groupified path even if the > api type specified legacy, so that would have caused you to start seeing > the new behavior. > > Regardless, we clearly didn't get the docs right and I apologize for it > impacting you. > > > >> and the Advanced Build Operations > Build Pruning >> <https://docs.openshift.com/container-platform/3.11/dev_guide/builds/advanced_build_operations.html#build-pruning> >> documentation >> implies default behavior is that no history limit is enforced on creation. >> > > Yup, thanks, that doc definitely needs to be fixed. Adam can you make > sure that happens? (Along w/ fixing the api doc) > > > >> We just happened to have someone accidentally delete a project's contents >> and discovered this after losing builds and their history unknowingly. >> Ideally, I would rather prefer BuildConfig pruning gave us the option of >> specifying a number of days to keep old Builds, but we'll make due as we >> don't have hard and fast retention requirements yet. >> > > We went with number because the primary concern was controlling the > amount/size of content being retained in etcd, which you don't get with a > time-bound constraint. But certainly offering both options is a reasonable > RFE (no promises it would get a high priority though) > > > > >> >> On Wed, Mar 27, 2019 at 2:14 PM Ben Parees <bpar...@redhat.com> wrote: >> >>> >>> >>> On Wed, Mar 27, 2019 at 11:58 AM Andrew Feller <afel...@bandwidth.com> >>> wrote: >>> >>>> Using a simple documented BuildConfig >>>> <https://docs.openshift.com/container-platform/3.11/dev_guide/builds/index.html>, >>>> we're seeing every newly created BuildConfig resource >>>> defaulting failedBuildsHistoryLimit and successfulBuildsHistoryLimit when >>>> documentation specifies BuildConfig not having default values and honoring >>>> preserving all builds. >>>> >>> >>> i'm assuming you're basing your statement on the api doc: >>> https://github.com/openshift/api/blob/release-3.11/build/v1/types.go#L904 >>> >>> (if you saw it somewhere else, please let us know). >>> >>> Unfortunately that doc is wrong... when we moved from legacy resource >>> types to grouped resource types, we introduced a default retention of 5 for >>> each type(successful and failed). If you created a buildconfig via the >>> legacy resource you got no limit, but if you create it via the grouped >>> resource (which is the default and what everyone should be doing now), you >>> got a default of 5 applied to your object. If you look at the >>> buildconfig.yaml (oc get bc/foo -o yaml) you will see that value appear >>> because it's actually applied to your object during creation. >>> >>> you can edit the bc and delete the field to switch to no retention, or >>> you can create your BCs with a very high retention. I don't think you can >>> actually create a BC w/ no retention limit, though, given how the system >>> works. >>> >>> >>> >>> >>> >>>> >>>> My knee jerk thought was to talk with my OCP administrators to see >>>> whether nodes were configured to default aspects of specific resource >>>> types, however we didn't see anything readily within master-config.yaml >>>> file on one of the masters. >>>> >>>> Any assistance is appreciated! >>>> >>>> >>>>> me@me-mbp ~ $ oc version >>>> >>>> oc v3.11.0+0cbc58b >>>> >>>> kubernetes v1.11.0+d4cacc0 >>>> >>>> features: Basic-Auth >>>> >>>> >>>>> Server ... >>>> >>>> openshift v3.11.43 >>>> >>>> kubernetes v1.11.0+d4cacc0 >>>> >>>> >>>> >>>> me@me-mbp ~ $ oc new-project ruby-sample >>>> >>>> >>>>> me@me-mbp ~ $ cat << EOF | oc apply -f - -n ruby-sample >>>>> > kind: "BuildConfig" >>>>> > apiVersion: "v1" >>>>> > metadata: >>>>> > name: "ruby-sample-build" >>>>> > spec: >>>>> > runPolicy: "Serial" >>>>> > triggers: [] >>>>> > source: >>>>> > git: >>>>> > uri: "https://github.com/openshift/ruby-hello-world"; >>>>> > strategy: >>>>> > sourceStrategy: >>>>> > from: >>>>> > kind: "ImageStreamTag" >>>>> > name: "ruby-20-centos7:latest" >>>>> > EOF >>>>> buildconfig.build.openshift.io/ruby-sample-build created >>>> >>>> >>>>> me@me-mbp ~ $ oc get -o yaml bc ruby-sample-build >>>>> apiVersion: build.openshift.io/v1 >>>>> kind: BuildConfig >>>>> metadata: >>>>> annotations: >>>>> kubectl.kubernetes.io/last-applied-configuration: | >>>>> {"apiVersion":"build.openshift.io/v1 >>>>> ","kind":"BuildConfig","metadata":{"annotations":{},"name":"ruby-sample-build","namespace":"ruby-sample"},"spec":{"runPolicy":"Serial","source":{"git":{"uri":" >>>>> https://github.com/openshift/ruby-hello-world >>>>> "}},"strategy":{"sourceStrategy":{"from":{"kind":"ImageStreamTag","name":"ruby-20-centos7:latest"}}},"triggers":[]}} >>>>> creationTimestamp: 2019-03-27T15:49:28Z >>>>> name: ruby-sample-build >>>>> namespace: ruby-sample >>>>> resourceVersion: "268668901" >>>>> selfLink: /apis/ >>>>> build.openshift.io/v1/namespaces/ruby-sample/buildconfigs/ruby-sample-build >>>>> uid: e7a55eaa-50a7-11e9-982c-001a4aa86606 >>>>> spec: >>>>> failedBuildsHistoryLimit: 5 >>>>> nodeSelector: null >>>>> output: {} >>>>> postCommit: {} >>>>> resources: {} >>>>> runPolicy: Serial >>>>> source: >>>>> git: >>>>> uri: https://github.com/openshift/ruby-hello-world >>>>> type: Git >>>>> strategy: >>>>> sourceStrategy: >>>>> from: >>>>> kind: ImageStreamTag >>>>> name: ruby-20-centos7:latest >>>>> type: Source >>>>> successfulBuildsHistoryLimit: 5 >>>>> triggers: [] >>>>> status: >>>>> lastVersion: 0 >>>> >>>> >>>> >>>> -- >>>> >>>> [image: BandwidthMaroon.png] >>>> >>>> Andy Feller • Sr DevOps Engineer >>>> >>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606 >>>> >>>> >>>> e: afel...@bandwidth.com >>>> _______________________________________________ >>>> users mailing list >>>> users@lists.openshift.redhat.com >>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>> >>> >>> >>> -- >>> Ben Parees | OpenShift >>> >>> >> >> -- >> >> [image: BandwidthMaroon.png] >> >> Andy Feller • Sr DevOps Engineer >> >> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606 >> >> >> e: afel...@bandwidth.com >> > > > -- > Ben Parees | OpenShift > > -- ADAM KAPLAN SENIOR SOFTWARE ENGINEER - OPENSHIFT Red Hat <https://www.redhat.com/> 100 E Davie St Raleigh, NC 27601 USA adam.kap...@redhat.com T: +1-919-754-4843 IM: adambkaplan <https://red.ht/sig>
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
