Thanks Ben and Adam for the follow up and filing bugs! I will follow up regarding the RFE; thanks for the direction
On Thu, Mar 28, 2019 at 9:34 AM Adam Kaplan <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Thu, Mar 28, 2019 at 6:48 AM Andrew Feller <[email protected]> >> 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 <[email protected]> wrote: >>> >>>> >>>> >>>> On Wed, Mar 27, 2019 at 11:58 AM Andrew Feller <[email protected]> >>>> 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: [email protected] >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> 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: [email protected] >>> >> >> >> -- >> Ben Parees | OpenShift >> >> > > -- > > ADAM KAPLAN > > SENIOR SOFTWARE ENGINEER - OPENSHIFT > > Red Hat <https://www.redhat.com/> > > 100 E Davie St Raleigh, NC 27601 USA > > [email protected] T: +1-919-754-4843 IM: adambkaplan > <https://red.ht/sig> > -- [image: BandwidthMaroon.png] Andy Feller • Sr DevOps Engineer 900 Main Campus Drive, Suite 500, Raleigh, NC 27606 e: [email protected]
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
