Wednesday, 2017-11-08

pabelangerSpamapS: for the purpose of the installfest, we basically did the following: https://etherpad.openstack.org/p/SYD-windmill-101 The idea was just to have 'software' configure everything, which it could (in future) but was a quick way to setup dependencies and services in place.00:10
*** ricky_summit has quit IRC00:18
SpamapSpabelanger: cool, yeah windmill may be simpler than hoist. :)00:47
*** qwc has quit IRC01:01
*** qwc has joined #zuul01:09
*** qwc has quit IRC01:36
*** qwc has joined #zuul01:42
*** qwc has quit IRC01:52
*** qwc has joined #zuul02:15
*** jkilpatr has quit IRC02:21
*** qwc has quit IRC02:23
*** qwc has joined #zuul02:28
*** ricky_summit has joined #zuul02:34
*** qwc has quit IRC02:35
*** qwc has joined #zuul02:42
*** ricky_summit has quit IRC03:03
*** bhavik1 has joined #zuul05:49
*** bhavik1 has quit IRC06:15
*** xinliang has quit IRC07:26
*** xinliang has joined #zuul07:43
*** hashar has joined #zuul07:45
*** xinliang has quit IRC08:17
*** xinliang has joined #zuul08:30
*** xinliang has quit IRC08:30
*** xinliang has joined #zuul08:30
*** hogepodge has quit IRC09:43
*** timrc has quit IRC09:43
*** jamielennox has quit IRC09:43
*** mordred has quit IRC09:43
*** rbergeron has quit IRC09:43
*** mrhillsman has quit IRC09:43
*** electrofelix has joined #zuul09:48
*** hogepodge has joined #zuul09:49
*** timrc has joined #zuul09:49
*** jamielennox has joined #zuul09:49
*** mordred has joined #zuul09:49
*** rbergeron has joined #zuul09:49
*** mrhillsman has joined #zuul09:49
*** lennyb has quit IRC10:48
*** hashar is now known as hasharAway10:50
*** lennyb has joined #zuul11:45
*** jkilpatr has joined #zuul12:32
*** xinliang has quit IRC12:39
*** xinliang has joined #zuul12:53
*** bhavik1 has joined #zuul12:57
*** xinliang has quit IRC13:19
*** xinliang has joined #zuul13:23
*** bhavik1 has quit IRC13:27
*** dkranz has joined #zuul14:15
*** Guest5156 has joined #zuul14:48
*** Guest5156 has quit IRC14:52
*** dkranz has left #zuul14:55
odyssey4meI'm doing some work to implement nodepool v3 in our org for testing. We're still using jenkins for now and don't want to switch from jenkins to zuul just yet... but we definitely want to use nodepool.15:58
odyssey4meI have a working implementation up and am trying to understand how I can have jenkins consume nodes from nodepool given nodepool v3.15:58
odyssey4meIn nodepool v2/v2.5 it appears that gearman and zeromq were involved... I need a little help connecting the dots if someone is able to help with that. In a previous chat with mordred there was mention made of there being a wish for a new jenkins plugin for nodepool v3... so I'm happy to help there, but would like a little help gaining enough understanding of what the integration needs to be to make that happen.16:01
dmsimardodyssey4me: in v2, zuul jenkins and nodepool communicate with each other through geard, yes16:15
dmsimardodyssey4me: review.rdoproject.org still uses a setup with zuul v2 with jenkins and nodepool16:15
dmsimardnodepool (v2) adds the nodes to jenkins as slaves (i.e, https://github.com/openstack-infra/nodepool/blob/master/nodepool/jenkins_manager.py )16:16
dmsimardthat code is gone from nodepool v316:17
dmsimardand then zuul allocates a job to run on a slave16:17
dmsimardif you don't run zuul, you could probably have logic to run jobs based on labels https://github.com/openstack-infra/nodepool/blob/master/nodepool/jenkins_manager.py#L5416:18
dmsimardSo basically nodepool would create a slave in jenkins with label, say, 'centos-7' (even though the slave is going to be name centos-7-34832987292) and then in your jenkins jobs, you restrict the jobs to run only on slaves with that particular label16:19
dmsimardI'm not sure what triggers the eventual deletion of the slave without a zuul involved, though16:20
odyssey4mewell, if I understand it correctly all nodes are now in zookeeper and all nodepool's understanding of the node's state comes from there16:34
odyssey4meso I'm guessing that whatever zuul does to set node states in that inventory is the same that needs to be done by jenkins16:35
*** jkilpatr has quit IRC16:41
dmsimardodyssey4me: zookeeper came with nodepoolv3, if you use v3 there's no native integration for jenkins (yet)16:45
dmsimardnodepool v2, with jenkins support, does not use zookeper16:45
dmsimardzookeeper*16:45
*** openstackgerrit has quit IRC16:48
*** jkilpatr has joined #zuul16:54
odyssey4medmsimard yes, that's the point - I want to build the integration so I'm trying to understand the flow of work and where jenkins would need to interface17:01
dmsimardahhh :)17:02
dmsimardafraid I can't quite help you there17:02
dmsimardShrews would be able to point you in the right direction17:03
*** jkilpatr has quit IRC17:05
*** jkilpatr has joined #zuul17:18
odyssey4medmsimard it would appear that you helped me think in the right direction - it would seem that https://github.com/openstack-infra/zuul/blob/feature/zuulv3/zuul/nodepool.py is a good place to start17:32
dmsimardI was not useless /o/17:36
leifmadsenhuzzuh!17:50
Shrewsodyssey4me: as far as <something> communicating with nodepool to request nodes, it only understands the simple request protocol somewhat outlined in the zuulv3 spec: http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html17:52
odyssey4meShrews yeah, I have that referenced too17:52
Shrewsodyssey4me: that's pretty simple to implement. the jenkins side of it would have to be handled by a backend driver of sorts that you'd have to create17:53
Shrewssee nodepool/drivers/*17:53
Shrewsodyssey4me: but i've never actually done much with jenkins, so i've no idea what that would look like17:54
odyssey4meShrews hmm, I hadn't thought of the driver interface17:54
odyssey4meI'm guessing it may make sense to do something similar to what there was before - have a jenkins plugin which publishes and subscribes events, then a driver to consume those17:55
Shrewsodyssey4me: nodepool didn't really have a concept of "drivers" until just recently when tristanC (iirc) broke that code out. so it's still somewhat in development, i think17:55
odyssey4methe alternative would be to totally decouple it and work through zookeeper exclusively - jenkins <-> zookeeper <-> nodepool17:56
Shrewsodyssey4me: i could see a jenkins plugin that speaks the zookeeper protocol, making the request/response handling17:56
Shrewsthat actually makes more sense in my mind, and doesn't require nodepool changes17:57
odyssey4meyeah, the only thing it requires is for the data model in zookeeper to be consistent17:57
odyssey4methat's easy enough to manage though - each plugin version is tested against a specific nodepool version17:59
odyssey4meand that's that17:59
Shrewsodyssey4me: We don't do any sort of versioning of that. We've tried not to change any existing data values, but only add new ones as we see the need. Code just sort of looks for the data fields it needs, ignoring any irrelevant data. I'd imagine the plugin could do the same.18:00
Shrewsjeblair's handling of that in the zuul data model is actually very flexible, and a good model to follow.18:00
odyssey4meyeah, good plan18:00
Shrewszuul/zk.py, fwiw18:01
Shrewsoh, no. zuul/model.py, i think18:01
*** openstackgerrit has joined #zuul18:02
openstackgerritMerged openstack-infra/zuul-jobs master: Add nodejs-npm jobs  https://review.openstack.org/51780818:02
openstackgerritMerged openstack-infra/zuul-jobs master: Collect npm-shrinkwrap for javascript  https://review.openstack.org/51777418:02
Shrewssee the Node class for a good example18:02
*** jkilpatr has quit IRC18:05
odyssey4meShrews dmsimard thank you for helping me coalesce the right bits - with a fresh head I'll revisit this tomorrow and see if I can knock up some sort of PoC/hack to validate it18:12
*** jkilpatr has joined #zuul18:18
*** jkilpatr has quit IRC19:00
*** electrofelix has quit IRC19:11
*** jkilpatr has joined #zuul19:12
*** jkilpatr_ has joined #zuul20:32
*** jkilpatr has quit IRC20:35
openstackgerritMatthieu Huin proposed openstack-infra/nodepool feature/zuulv3: Document security group  https://review.openstack.org/51862021:19
mordredopenstackgerrit: morning!21:22
mordredodyssey4me, Shrews: https://etherpad.openstack.org/p/zuulv3-jenkins-integration is the etherpad I wrote up with thoughts on possibilities for jenkins integratoin21:22
dmsimardmordred: I see a use case for using jenkins with nodepool (without zuul), but using nodepool+zuul+jenkins ??21:24
dmsimard(especially with v3)21:25
mordreddmsimard: yes - I think both things are valid use cases ...21:29
mordreddmsimard: for one, an org could keep one nodepool that is shared between a zuul and a jenkins - or between several jenkinses21:29
dmsimardmordred: so s/zuul-executor/jenkins/ ?21:29
dmsimardoh, in that sense21:29
mordreddmsimard: but also it's possible there is a jenkins pipeline something job that someone really needs to keep - so having a zuul job that can trigger it seems perfectly valid too21:30
mordredalso - stepwise migratoin :)21:30
*** jkilpatr_ has quit IRC21:32
*** jkilpatr has joined #zuul21:57

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!