Thanks Gabe, I’ve actually raised two issues. One relating to the background update and one relating to changing docs to encourage the use of the ConfigMap. The latter may not be of use but I thought it might be, discard as necessary.
Thanks for the ConfigMap approach, I’ll experiment with that. Alan Christie achris...@informaticsmatters.com > On 17 Jul 2018, at 15:43, Gabe Montero <gmont...@redhat.com> wrote: > > > > On Tue, Jul 17, 2018 at 9:09 AM, Alan Christie > <achris...@informaticsmatters.com <mailto:achris...@informaticsmatters.com>> > wrote: > Hi Gabe, > > I’m annotating the ImageStream, essentially doing this: `slave-label: > buildah-slave`. The Dockerfile and ImageStream YAML template for my agent (a > buildah/skopeo agent) based on jenkins-slave-maven-centos can be found at our > public repo > (https://github.com/InformaticsMatters/openshift-jenkins-buildah-slave > <https://github.com/InformaticsMatters/openshift-jenkins-buildah-slave>). > > I can understand the agent being replaced when the external image changes but > I was curious about why it might change (for no apparent reason). > > Just remembered, our background polling mechanism is most likely updating it. > It gets back to not being able to merge our partial config > with any changes you've made on the Jenkins side. That said, we could try to > avoid the update if our partial config matches. > > Open an issue against https://github.com/openshift/jenkins-sync-plugin > <https://github.com/openshift/jenkins-sync-plugin>, and I can look into that. > Also, we should update our docs to encourage > folks to use the ConfigMap approach if they are modifying the PodTemplate > config beyond the basics we employ. > > > But ... I will take a look at the configMap approach because that sounds a > lot more useful - especially for a CI/CD process and would allow me to set > the agent up from the command-line without having to use the Jenkins > management console. > > Where might I find a good reference example for the ConfigMap approach? > > Check out > https://docs.openshift.org/latest/using_images/other_images/jenkins.html#configuring-the-jenkins-kubernetes-plug-in > > <https://docs.openshift.org/latest/using_images/other_images/jenkins.html#configuring-the-jenkins-kubernetes-plug-in> > > > Alan Christie > achris...@informaticsmatters.com <mailto:achris...@informaticsmatters.com> > > > >> On 17 Jul 2018, at 13:18, Gabe Montero <gmont...@redhat.com >> <mailto:gmont...@redhat.com>> wrote: >> >> Hi Alan, >> >> Are you leveraging our feature to inject agents by labelling ImageStreams >> with >> the label "role" set to a value of "jenkins-slave", or annotating an >> ImageStreamTag >> with the same k/v pair? >> >> If so, that is going to update the agent definition every those items are >> are updated >> in OpenShift. And there is currently no merging of the partial PodTemplate >> config >> we construct from ImageStream / ImageStreamTags with whateve modifications to >> the PodTemplate was made from within Jenkins after the agent is initially >> created >> (there are no k8s API we can leverage to do that). >> >> If the default config we provide for IS/ISTs is not sufficient, I would >> suggest switching >> to our ConfigMap version of this injection. With that form, you can specify >> the >> entire PodTemplate definition, including the settings you noted below, where >> the image >> for the PodTemplate is the docker ref for the IS/IST you are currently >> referencing. >> >> If you are inject agents in another way, please elaborate and we'll go from >> there. >> >> thanks, >> gabe >> >> On Tue, Jul 17, 2018 at 4:45 AM, Alan Christie >> <achris...@informaticsmatters.com <mailto:achris...@informaticsmatters.com>> >> wrote: >> Hi, >> >> I’m using Jenkins on an OpenShift Origin 3.9.0 deployment and notice that >> Jenkins periodically forgets the additional settings for my custom agent. >> >> I’m using the built-in Jenkins from the catalogue (Jenkins 2.89.4) with all >> the plugins updated. >> >> Incidentally, I doubt it has anything to do with the origin release as >> I recall seeing this on earlier (3.7/3.6) releases. >> >> It happens when I deploy a new agent to Docker hub so this I can partly >> understand (i.e. a new ‘latest’ image is available so it’s pulled) - >> although I do struggle to understand why it creates a *new* Kubernetes pod >> template in the cloud configuration when one already exists for the same >> agent (but that’ll probably be the subject of another question). So, each >> time I push an image I have to fix the cloud configuration for my agent. >> >> This I can live with (for now) but it also happens periodically for no >> apparent reason. I’m not sure about the frequency but I’ll notice every >> week, or every few weeks, the Kubernetes Pod Template for my agent has >> forgotten all the _extra_ setup. Things like: - >> >> - Run in privileged mode >> - Additional volumes >> - Max number of instances >> - Time in minutes to retain slave when idle >> >> Basically anything adjusted beyond the defaults provided when you first >> instantiate an agent is lost. >> >> Has anyone reported this behaviour before? >> Is there a fix or can anyone suggest an area of investigation? >> >> Alan Christie >> achris...@informaticsmatters.com <mailto:achris...@informaticsmatters.com> >> >> >> >> >> _______________________________________________ >> users mailing list >> users@lists.openshift.redhat.com <mailto:users@lists.openshift.redhat.com> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >> <http://lists.openshift.redhat.com/openshiftmm/listinfo/users> >> >> > >
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
