https://pulumi.com logo
Powered by
c

creamy-potato-29402

09/04/2018, 4:39 AM
Not saying your wrong, I’m genuinely very curious!
f

fresh-king-3299

09/04/2018, 4:40 AM
let’s use this thread to cut down the noise for others
c

creamy-potato-29402

09/04/2018, 4:40 AM
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

fresh-king-3299

09/04/2018, 4:41 AM
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

creamy-potato-29402

09/04/2018, 4:45 AM
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

fresh-king-3299

09/04/2018, 4:47 AM
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

creamy-potato-29402

09/04/2018, 4:47 AM
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

fresh-king-3299

09/04/2018, 4:50 AM
I guess my main point is I want the option to retain the simple(istic) behavior of kubectl apply
c

creamy-potato-29402

09/04/2018, 4:51 AM
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

fresh-king-3299

09/04/2018, 4:56 AM
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

creamy-potato-29402

09/04/2018, 5:07 AM
@fresh-king-3299 ok, if I understand correctly, this scenario should still work if you manually provide 
.metadata.name
f

fresh-king-3299

09/04/2018, 5:42 AM
I’ll check it out. Thanks
c

creamy-potato-29402

09/04/2018, 5:51 AM
f

fresh-king-3299

09/04/2018, 5:56 AM
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
Powered by