https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
f
let’s use this thread to cut down the noise for others
c
good idea
(BTW, you can actually prevent the rollout from happening by manually specifying 
.metadata.name
— Pulumi implements this by autonaming the 
ConfigMap
, and if you specify a name manually, it will just update it in place.)
f
I use configmaps to configure my jenkins jobs. When I change the configmap, Kubernetes would update it in a volume in about a minute. Then I have Jenkins check for the config changes
c
I see, so you’re saying that you use Jenkins to trigger a rollout of the `Deployment`s?
i.e., it watches for changes to the 
ConfigMap
, and then triggers a pipeline based on those changes?
f
Actually I have a jenkins job that watches a git repo of yaml files. Whenever that repo changes then a jenkins job will kubectl apply all the yamls
but I digress. The jenkins configmaps for to changes the jenkins jobs themself
c
you can still do that, I think, by specifying 
.metadata.name
The update then happens in-place
so no rollout is triggered.
Also, if no deployments reference the 
ConfigMap
, no rollout would be triggered.
… if I understand what you’re saying
f
I guess my main point is I want the option to retain the simple(istic) behavior of kubectl apply
c
Right, totally get it. I’m just trying to capture why this is important in the form of a pithy use case I can take back to the team. 🙂
f
my jenkins config must be a 1000 line long but here is a snippet
Copy code
containers:
        - name: jenkins
          image: <http://registry.rebelsoft.com/jenkins:latest|registry.rebelsoft.com/jenkins:latest>
          env:
          - {name: KMASTER, value: "{{ ETCD_HOST }}"}
          - {name: CONTEXT, value: "/jenkins"}
          volumeMounts:
          - name: jenkins-install
            mountPath: "/root/.jenkins/jobs/SYSTEM INSTALL"
          - name: jenkins-seed
            mountPath: "/root/.jenkins/jobs/SYSTEM SEED"
          - name: jenkins-seed-groovy
            mountPath: "/root/.jenkins/jobs/SYSTEM SEED/workspace"
          - name: docker
            mountPath: /var/run/docker.sock
          - name: data
            mountPath: "/root/.jenkins/"
            subPath: jenkins
        volumes:
        - name: jenkins-config
          configMap:
            name: jenkins-config
        - name: jenkins-install
          configMap:
            name: jenkins-install
        - name: jenkins-seed
          configMap:
            name: jenkins-seed
            items:
            - key: config.xml
              path: config.xml
        - name: jenkins-seed-groovy
          configMap:
            name: jenkins-seed
            items:
            - key: seed.groovy
              path: seed.groovy
All the jenkins config files comes from configmaps. And whenever those configmaps changes Jenkins would simply pickup the changes once Kubernets updates the volumemounts
no need or desire to re-deploy jenkins since that will cause an outage
c
@fresh-king-3299 ok, if I understand correctly, this scenario should still work if you manually provide 
.metadata.name
f
I’ll check it out. Thanks
c
f
The fix looks good.
Yet having used kubernetes for the last 3-4 years it just seems very wrong for kubernetes services to wait for endpoints. But we beat that to death already
3 Views
Open in Slack
PreviousNext
Powered by