| *** ctlaugh_ has joined #openstack-sprint | 05:47 | |
| *** ig0r__ has joined #openstack-sprint | 05:51 | |
| *** ig0r_ has quit IRC | 05:52 | |
| *** rfolco has quit IRC | 06:09 | |
| *** rfolco has joined #openstack-sprint | 06:21 | |
| *** mestery_ has joined #openstack-sprint | 13:06 | |
| *** mestery has quit IRC | 13:09 | |
| *** mestery_ has quit IRC | 13:48 | |
| *** eantyshev has joined #openstack-sprint | 14:09 | |
| *** yolanda has joined #openstack-sprint | 14:29 | |
| *** anteaya has joined #openstack-sprint | 14:38 | |
| anteaya | can we get an updated topic at some point? | 14:39 |
|---|---|---|
| *** rfolco has quit IRC | 14:51 | |
| *** rfolco has joined #openstack-sprint | 14:51 | |
| jeblair | yep, what's the etherpad? | 15:04 |
| yolanda | https://etherpad.openstack.org/p/common-ci-sprint | 15:06 |
| *** rfolco has quit IRC | 15:12 | |
| *** rfolco has joined #openstack-sprint | 15:14 | |
| *** ChanServ changes topic to "Common CI Sprint | https://etherpad.openstack.org/p/common-ci-sprint" | 15:23 | |
| *** TravT has left #openstack-sprint | 15:46 | |
| *** asselin has joined #openstack-sprint | 15:55 | |
| asselin | hi, who's here for the common ci sprint? | 16:00 |
| yolanda | hi asselin, i need to run for a while, but will come back later | 16:01 |
| *** crinkle has joined #openstack-sprint | 16:02 | |
| asselin | yolanda, sure | 16:03 |
| ctlaugh_ | asselin: I am here, but am having extreme technical difficulties getting a setup that I can run anything on. | 16:05 |
| ctlaugh_ | I'm still rebuilding my setup after having to move between labs. | 16:07 |
| asselin | ctlaugh_, ok, please help as you can | 16:07 |
| *** nibalizer has joined #openstack-sprint | 16:09 | |
| nibalizer | hiya | 16:09 |
| nibalizer | we sprinting today? | 16:09 |
| asselin | nibalizer, yes we are! | 16:10 |
| eantyshev | hello! I can help testing sample CI solution | 16:10 |
| mmedvede | I am here | 16:11 |
| asselin | nibalizer, I can help out with the sample 3rd party ci task | 16:12 |
| nibalizer | cool | 16:16 |
| asselin | mmedvede, hi, I think your patch is reeady to merge https://review.openstack.org/#/c/198546/. nibalizer want to do a quick review? | 16:16 |
| nibalizer | sure | 16:16 |
| mmedvede | asselin: nibalizer: this one needs to go first https://review.openstack.org/#/c/184353/ | 16:17 |
| * asselin looks | 16:18 | |
| jeblair | i probably won't be able to really join the sprint for a couple of hours, will let you know when i'm really available | 16:20 |
| yolanda | hi nibalizer | 16:22 |
| *** zaro has joined #openstack-sprint | 16:22 | |
| zaro | hiho | 16:22 |
| zaro | asselin: can't tell why this one is failing https://review.openstack.org/#/c/199335/ any ideas? | 16:23 |
| asselin | zaro, mmedvede fyi your patches will conflict a bit: 184919 & 198546 | 16:24 |
| asselin | zaro, let me look...did you recheck since your latest patch? | 16:24 |
| asselin | zaro, rechecking | 16:25 |
| zaro | no, i have not done recheck | 16:25 |
| asselin | zaro, I looked before but couldn't find the error. My guess is the duplicate resource definition | 16:25 |
| asselin | zaro, let's see what happens with your update | 16:25 |
| nibalizer | mmedvede: the dependent patch needs a fix up | 16:26 |
| nibalizer | asselin: please do funnel reviews my way | 16:28 |
| mmedvede | nibalizer: ok, thanks | 16:28 |
| nibalizer | downstream-puppet is our topic ya? | 16:28 |
| asselin | nibalizer, sure | 16:28 |
| asselin | nibalizer, yes...I added it to the etherpad | 16:29 |
| nibalizer | im realizing my role might be to just review things rather than try to write | 16:29 |
| nibalizer | we'll see | 16:29 |
| asselin | I'd like to get nodepool done today | 16:29 |
| asselin | then tomorrow we can put the whole thing together | 16:30 |
| asselin | JJB is low hanging fruit and would be good to get done soon | 16:30 |
| nibalizer | i think there is os-client-config stuff that needs to happen to do nodepool | 16:31 |
| nibalizer | yolanda and I were going to sync up on that but haven't yet | 16:31 |
| nibalizer | right now there are no reviews against puppet-os-client-config | 16:32 |
| asselin | link? | 16:32 |
| nibalizer | https://review.openstack.org/#/q/status:open+os_client,n,z | 16:32 |
| nibalizer | so I believe the plan is to push credentials out of nodepool.yaml into the os_client_config module which will open us up to moving those declarations into openstackci | 16:33 |
| nibalizer | I *think* | 16:33 |
| nibalizer | I'm just a passenger on that effort, not driving it | 16:33 |
| zaro | asselin: does this require a fix? https://review.openstack.org/#/c/184919/8/manifests/jenkins_job_builder.pp | 16:35 |
| asselin | zaro, yes I believe so | 16:36 |
| zaro | ok another patch coming | 16:37 |
| zaro | yolanda: had a question on this https://review.openstack.org/#/c/188372/ | 16:47 |
| asselin | mmedvede, there are a few other places that can benefit from your project-config revision change | 16:55 |
| yolanda | hi, back | 16:55 |
| mmedvede | asselin: I would rebase 198546 on top of 184919, does it sound good? Or I can wait for 198546 to land first | 16:55 |
| mmedvede | asselin: yes. I can do a blanket patch | 16:55 |
| asselin | mmedvede, either way | 16:56 |
| yolanda | zaro, going to amend the commit message. I need the depends-on to be in the way it is, first drop policycoreutils-python, then update selinux, otherwise it will fail due to duplication | 16:57 |
| yolanda | nibalizer, yes, in order to continue with nodepool stuff, we need that os-client-config module | 16:58 |
| yolanda | to setup clouds.yaml config | 16:58 |
| * asselin goes to a meeting. back in about 30 mins | 16:59 | |
| nibalizer | ok | 17:02 |
| nibalizer | yolanda: I'll build out puppet-os_client_config | 17:06 |
| yolanda | cool | 17:08 |
| zaro | yolanda: was wondering what will pass jenkins_masters into this? https://review.openstack.org/#/c/188325 | 17:17 |
| yolanda | zaro, it needs to be referenced properly in system-config, passing the right jenkins-masters values there | 17:19 |
| yolanda | zaro, it is needed, along with the nodepool change, and a pending change for os-cloud-config, for the nodepool puppet-openstackci | 17:21 |
| zaro | yolanda: ahh ok, it's not there yet. | 17:30 |
| yolanda | no, not yet, sorry | 17:38 |
| * asselin returns | 17:51 | |
| * nibalizer still working on oscc | 17:53 | |
| * zaro is reviewing | 17:58 | |
| * anteaya joins and having read scrollback thinks reviewing is a reasonable place to begin | 17:59 | |
| asselin | this patch is ready for merge imho https://review.openstack.org/#/c/184919/9 | 18:01 |
| *** pabelanger has joined #openstack-sprint | 18:01 | |
| asselin | passes in my env, but not sure why it fails in the needed-by system-config patch: https://review.openstack.org/#/c/199335/ | 18:01 |
| *** mestery has joined #openstack-sprint | 18:01 | |
| asselin | anteaya, nibalizer any ideas? ^^ | 18:02 |
| nibalizer | ill look in a sec | 18:03 |
| *** Daviey has joined #openstack-sprint | 18:04 | |
| nibalizer | ya it looks like the test didn't really run the core of the tests | 18:05 |
| pleia2 | had a busy morning, but I'm around now o/ | 18:08 |
| nibalizer | hi | 18:08 |
| pleia2 | and I have juice | 18:09 |
| anteaya | yay juice | 18:09 |
| anteaya | nibalizer: this is the first I am looking at a log file for apply tests, how can you tell what tests completed successfully and what tests just were not executed? | 18:11 |
| * asselin also would like to know | 18:12 | |
| nibalizer | http://logs.openstack.org/46/198546/1/check/gate-infra-puppet-apply-precise/148bc82/console.html | 18:16 |
| nibalizer | is an example of correct behavior | 18:16 |
| nibalizer | there is puppet apply output | 18:16 |
| nibalizer | and the puppet code that is being run is also printed | 18:16 |
| nibalizer | yolanda: oscc patches proposed | 18:18 |
| anteaya | so is this where the tests actually start being run? http://logs.openstack.org/46/198546/1/check/gate-infra-puppet-apply-precise/148bc82/console.html#_2015-07-05_14_39_05_036 | 18:19 |
| nibalizer | this line http://logs.openstack.org/46/198546/1/check/gate-infra-puppet-apply-precise/148bc82/console.html#_2015-07-05_14_36_22_170 | 18:21 |
| nibalizer | first it does 'module installation' which is very very noisy | 18:21 |
| yolanda | nibalizer, going to take a look | 18:21 |
| anteaya | I concur on very noisy | 18:22 |
| anteaya | nibalizer: so what do you suggest, another recheck? | 18:23 |
| anteaya | what would cause the core of the tests to not really run? | 18:24 |
| nibalizer | i think so | 18:24 |
| anteaya | okey dokey | 18:24 |
| nibalizer | I'm just now closing the oscc loops up so that I can page this in | 18:24 |
| nibalizer | so I'm not 100% sure | 18:24 |
| nibalizer | looking more intently now | 18:24 |
| nibalizer | also, did we scope this sprint to include changing system-config? | 18:24 |
| nibalizer | or just push stuff into puppet-openstackci | 18:24 |
| asselin | nibalizer, yes, includes system-config | 18:24 |
| anteaya | for me the scope of teh sprint is common ci | 18:25 |
| asselin | well....That's what I had in mind at least | 18:25 |
| yolanda | nibalizer, is $kernel , a fact that can be used on manifests? | 18:25 |
| anteaya | so that includes anything to get a new ci person to standing up a ci, for me | 18:25 |
| nibalizer | yolanda: ya | 18:25 |
| nibalizer | $: facter kernel | 18:25 |
| nibalizer | Linux | 18:25 |
| asselin | in general we've been merging both around the same time | 18:26 |
| yolanda | nibalizer, and the intention is that this module support site wide configuration, and user configuration? | 18:27 |
| * zaro afk for a few hrs. bb later | 18:28 | |
| nibalizer | sure | 18:28 |
| asselin | but I'm open to scoping that out as it isn't technically needed for third party ci setup... | 18:29 |
| yolanda | nibalizer, can you specify that behaviour, and the paths of the site config, in the documentaiton, on README.md? should be easier for end users to understand | 18:29 |
| yolanda | ah, and i love that to_yaml construct, would have saved me from some ugly template constructs | 18:30 |
| nibalizer | asselin: i feel like we dont need things to be in system-config for today | 18:31 |
| nibalizer | and pushing stuff live in -infra's production is going to slow down progress, and if anything breaks we'll lose our infra cores while they try to fix things | 18:32 |
| yolanda | nibalizer, reviewed | 18:33 |
| asselin | nibalizer, ok, then let's hold off on those. we can reevaluate towards the end of the sprint. | 18:34 |
| asselin | mmedvede, a few issues with https://review.openstack.org/#/c/184353/ | 18:41 |
| nibalizer | huh | 18:42 |
| nibalizer | maybe i need a periodic job | 18:42 |
| nibalizer | on system-config to run the apply test and emial me the results | 18:43 |
| nibalizer | anteaya: looks like it failed again | 18:45 |
| nibalizer | so i'm proposing a dummy change to sysemt-config to see if we have an environmental problem | 18:45 |
| *** TravT has joined #openstack-sprint | 18:48 | |
| anteaya | nibalizer: okay sounds good | 18:48 |
| asselin | mmedvede, digging in a bit, I think it doesn't work b/c JJB doesn't also have that revision, so it's defaulting to master | 18:51 |
| nibalizer | asselin: re: 184353 I think infra has been pasing a revision with facter for a while | 18:52 |
| nibalizer | pleia2: can you confirm? | 18:52 |
| mmedvede | asselin: I am testing it on my setup right now | 18:52 |
| asselin | and I guess that's the reason to use factor. If you specify a different revision for each invocation, the result is not defined | 18:53 |
| * pleia2 inspects | 18:54 | |
| nibalizer | im looking at system-config ansible things | 18:54 |
| nibalizer | and mostly I'm just not sure what all everything is doing | 18:54 |
| anteaya | sounds like you just summed up my life | 18:55 |
| *** mordred has joined #openstack-sprint | 18:55 | |
| mordred | sup? | 18:55 |
| pleia2 | nibalizer: I think you're right | 18:55 |
| pleia2 | o/ mordred | 18:55 |
| *** clarkb has joined #openstack-sprint | 18:56 | |
| nibalizer | heyo | 18:56 |
| pleia2 | just seeing if I can find other examples of us doing this | 18:56 |
| jeblair | mordred: nibalizer had some questions about ansible | 18:57 |
| anteaya | mordred: backscroll http://eavesdrop.openstack.org/irclogs/%23openstack-sprint/%23openstack-sprint.2015-07-08.log.html | 18:57 |
| pleia2 | since I'm not really sure how ensure and revision work together | 18:57 |
| jeblair | and i'm working on stuffing my face right now | 18:57 |
| jeblair | (but should be able to join after lunch) | 18:57 |
| anteaya | lunch is important | 18:57 |
| pleia2 | jeblair: enjoy :) | 18:57 |
| mordred | jeblair: searching for ansible on that page is giving me the sads | 18:58 |
| clarkb | ansible does not grep in the logs fwiw | 18:58 |
| clarkb | mordred: I think because we http them now so its not realtime | 18:58 |
| jeblair | http://eavesdrop.openstack.org/irclogs/%23openstack-sprint/%23openstack-sprint.2015-07-08.log | 18:58 |
| clarkb | you have to wait for cron to fire and pick up the latest http render | 18:58 |
| anteaya | the new logging doesnt keep pace with the conversation | 18:58 |
| jeblair | the 'not http' is realtime | 18:58 |
| anteaya | ah | 18:58 |
| jeblair | so just delete .html from the end of the url | 18:58 |
| anteaya | thank you | 18:59 |
| nibalizer | so my question is: "do we pass a project_conifg revision via ansible right now" ? | 18:59 |
| mordred | ah | 18:59 |
| clarkb | nibalizer: yes | 18:59 |
| mordred | nibalizer: what clarkb said | 18:59 |
| clarkb | via https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/ansible/playbooks/remote_puppet_git.yaml | 19:00 |
| pleia2 | ah, it's noon! I have a lunch to get to myself, bbiab | 19:00 |
| anteaya | pleia2: happy food to you too | 19:00 |
| clarkb | see the comment there about what the git module does, it basically asks git for HEAD, saves that value, and passes that value into the subseuent runs | 19:00 |
| clarkb | now we only do this for that one playbook | 19:00 |
| clarkb | as the git stuff was the only one sensitive to it changing | 19:00 |
| mordred | obvs we'll likely need to do something similar for the modules when we puppet apply | 19:01 |
| nibalizer | neat | 19:02 |
| mordred | OR - we might want to just rsync them or something ... that has not been designed yet | 19:02 |
| nibalizer | haha! | 19:02 |
| nibalizer | okay so asselin your concerns are unwarranted | 19:02 |
| nibalizer | if others are lunching then I will lunch to keep us in sync | 19:02 |
| anteaya | happy lunch | 19:02 |
| asselin | nibalizer, ok you'll have to explain after lunch | 19:02 |
| nibalizer | clarkb: mordred see https://review.openstack.org/#/c/184353/ | 19:03 |
| * asselin also goes to lunch | 19:03 | |
| clarkb | nibalizer: asselin that change should be fine | 19:04 |
| clarkb | ensure latest is required otherwise vcsrepo won't change the revision | 19:04 |
| mordred | nibalizer: agree with clarkb | 19:04 |
| clarkb | so the two comments there are related, you need them both set up that way to get things to update in puppet | 19:04 |
| clarkb | I do not think we will ever use the class parameter because it assumes you are not doing CD | 19:05 |
| nibalizer | ya okay | 19:05 |
| clarkb | so maybe there should be a comment there saying "please don't use this" and maybe that is enough reason to -2? | 19:05 |
| nibalizer | so landing that there could potentiall affect infra, so i'm not gonna land it until after lunch at least | 19:05 |
| nibalizer | or clarkb or mordred can +a (and maybe watch) it | 19:05 |
| asselin | mmedvede, ^^ | 19:05 |
| clarkb | well I want the comment at least | 19:05 |
| *** fungi has joined #openstack-sprint | 19:05 | |
| clarkb | I think its an anti pattern | 19:05 |
| clarkb | you want to always be running latest and greatest with the way project config works | 19:06 |
| clarkb | thats either master or some env specified revision | 19:06 |
| clarkb | neither of which are a class param | 19:06 |
| yolanda | hi, i need to leave for today, but will catch up tomorrow morning. Sorry for not participating so much today | 19:06 |
| nibalizer | seeya yolanda | 19:06 |
| fungi | checking in, i'm not around to really do the sprinting justice unfortunately. new house stuff is filling the next few days with random but nearly continuous interruptions | 19:06 |
| clarkb | just trying to think how you would pass a run specific revision via a class param and best I can come up with is pass the facter fact in | 19:07 |
| clarkb | so why not just use the fact? | 19:07 |
| anteaya | fungi: I hope new house stuff goes/is going smoothly | 19:07 |
| asselin | clarkb, this is also having a ripple effect in the other patches, e.g. https://review.openstack.org/#/c/198546/ | 19:08 |
| clarkb | asselin: ya thats what I was afraid of | 19:08 |
| clarkb | I think this got way too overcomplicated and doesn't serve a purpose | 19:08 |
| asselin | clarkb, and then this patch needs it too | 19:08 |
| clarkb | I am -1.5 on that | 19:08 |
| asselin | https://review.openstack.org/#/c/184919/ | 19:08 |
| mmedvede | clarkb: our usecase for using class param is that we have to different branches on our project_config (dev/master) that have two different configurations. Zuul that uses dev branch always runs latest, but from dev branch | 19:08 |
| clarkb | mmedvede: so use the fact? | 19:09 |
| mmedvede | clarkb: using custom fact is overkill for this | 19:09 |
| clarkb | its not FACTER_fact=foo | 19:09 |
| clarkb | done | 19:09 |
| nibalizer | well.... | 19:09 |
| nibalizer | that means you can't just run puppet agent | 19:09 |
| nibalizer | you have to do something fancy | 19:09 |
| clarkb | nibalizer: you have to run it with the env yes | 19:09 |
| nibalizer | now, technicall all you need is the variable set at top scope | 19:09 |
| mmedvede | clarkb: maybe I did misunderstand what custom fact means. Isn't it supposed to be provided by the node? | 19:09 |
| clarkb | mmedvede: no in our case its provided by ansible | 19:10 |
| clarkb | FACTER_foo=bar puppet agent --test | 19:10 |
| nibalizer | so you could just put $project_config_ref = 'master' in site.pp or the node def | 19:10 |
| clarkb | ya or ^ | 19:10 |
| nibalizer | er $::project_config_ref rather | 19:10 |
| *** krotscheck has joined #openstack-sprint | 19:10 | |
| mmedvede | clarkb: so it does require ansible use, which is not how many third-party CI do it, I think | 19:10 |
| clarkb | it does not require ansible | 19:10 |
| clarkb | see above | 19:11 |
| clarkb | we happen to have ansible set it but anything else can too | 19:11 |
| clarkb | also for third party CI with >1 node I would highly recommend ansible | 19:11 |
| nibalizer | clarkb: I think puppet master and puppet agent is a use case we should protect, though | 19:11 |
| mmedvede | clarkb: it does require creating more custom state for the node, instead of just being able to define it in hiera/site.pp | 19:11 |
| clarkb | nibalizer: yes and its 100% upported since that is exactly how that works today... | 19:12 |
| nibalizer | idunno | 19:12 |
| clarkb | we run a master, every node runs agent to check in and puppet | 19:12 |
| clarkb | today | 19:12 |
| nibalizer | clarkb: puppet agent in daemon mode | 19:12 |
| nibalizer | i guess is what i'm saying | 19:12 |
| clarkb | that is also supported... | 19:12 |
| clarkb | unless facter stopped working | 19:12 |
| mmedvede | nibalizer: correct, we run in daemon | 19:13 |
| nibalizer | not if you require puppet to be called with FACTER_fact=foo | 19:13 |
| clarkb | anyways I have an appointment in 45 minutes so have to pop out | 19:13 |
| clarkb | nibalizer: yes! | 19:13 |
| clarkb | write to /etc/facter | 19:13 |
| clarkb | put it in /etc/default/puppet | 19:13 |
| clarkb | put something in /usr/lib/ruby/facter/facts | 19:13 |
| clarkb | there are a million ways to do it | 19:13 |
| nibalizer | ya my pref would be site.pp because then you only change it in one place, not one place on every node | 19:14 |
| clarkb | the fact is sort of lowest common denominator make it work | 19:14 |
| clarkb | this is why it was chosen | 19:14 |
| nibalizer | but yea since you can set it in site.pp im not sure we need to be able to pick a revision in the jjb class | 19:14 |
| clarkb | nibalizer: ya thats a valid option too | 19:14 |
| asselin | mmedvede, can you test that out and see if it works for you? | 19:15 |
| clarkb | nibalizer: you can even put it in hiera | 19:15 |
| mmedvede | asselin: the current patch? Or creating custom facts on the node? | 19:15 |
| asselin | mmedvede, custom facts on the node via your preffered of clarkb's suggestions | 19:16 |
| clarkb | or setting it in site.pp or setting it in hiera | 19:16 |
| asselin | or nibalizer in site.pp | 19:16 |
| clarkb | my point is this was a deliberately chosen design to be accomodating as is | 19:17 |
| clarkb | I don't think we need to change it as the proposed changes don't really make it easier t use | 19:17 |
| clarkb | instead they make it more opinionated | 19:17 |
| * asselin goes to lunch now for real this time | 19:18 | |
| mmedvede | clarkb: I did not realize it is possible to set facter facts in hiera | 19:18 |
| mmedvede | or in site.pp | 19:18 |
| clarkb | mmedvede: its not really, but since we aren't specifically looking at a fact but a root level var we can set a root level var | 19:18 |
| clarkb | so at that point its just a variable not a fact but the end result is the same | 19:18 |
| clarkb | out of curiousity does putting the dev contents in the master branch not work for you? | 19:31 |
| clarkb | this is how we do it | 19:31 |
| clarkb | curious because maybe that needs to be rethought? | 19:32 |
| nibalizer | clarkb: i think I like the idea of passing in a revision | 19:32 |
| clarkb | nibalizer: the problem with that is it breaks the idea of CD project-config | 19:33 |
| nibalizer | if you say "I would like project-config" it makes sense also to say "I would like project-config at this revision" | 19:33 |
| clarkb | and you can do that | 19:33 |
| clarkb | we do it every run | 19:33 |
| clarkb | but we do not hard code that revision in puppet | 19:33 |
| clarkb | this is what I have issue with, either you cd off master or you are specifying a very volatile thing | 19:33 |
| nibalizer | it makes sense to say it in the same stanza | 19:33 |
| mmedvede | clarkb: our CI is different form OS infra is that we track dev and production on different branches, so it is a bit easier to see differences | 19:33 |
| clarkb | mmedvede: yes but the interface for project config that we have designed is to use one breanch | 19:34 |
| nibalizer | right so i understand why we need to do the external variable injection or variable lookup, because files in puppet code are static and this variable is dynamic | 19:34 |
| clarkb | mmedvede: this was considered when we made the project-config split, so now I am curious if that interface is not good enough | 19:34 |
| clarkb | anyways I think the current code allows one simple way to do it with a lot of flexibility | 19:35 |
| clarkb | the proposed code would add a new way to do it with much less flexibility so I am generaly not in favor | 19:35 |
| anteaya | well this needs to work for our infra, since the idea is that infra consumes the same set up | 19:35 |
| nibalizer | setting a global variable somewhere else to be picked up is a bit odd, and non-obvious | 19:36 |
| clarkb | anteaya: ya the proposed change adds a second redundant method we would continue using the old | 19:36 |
| anteaya | so having a situation where this reduces flexibilty for us doesn't really work | 19:36 |
| nibalizer | I think its totally viable that an organization would use a branch that is not master | 19:36 |
| clarkb | nibalizer: yup and we allow you to do that | 19:36 |
| nibalizer | for instance at hp we might use (probably will use) hp/master | 19:36 |
| clarkb | and yes this is the hiera problem | 19:37 |
| clarkb | global vars are clunky | 19:37 |
| clarkb | BUT I can't figure a better way to support volatile info like that | 19:37 |
| nibalizer | I think the facter fact is neat | 19:37 |
| nibalizer | it is very extensible | 19:37 |
| nibalizer | and the use of a top level varible at the end of the day makes it even more hackable | 19:38 |
| nibalizer | however, i think the project-config class can and should take a revision | 19:38 |
| clarkb | anyways I am not going to -1 the changes, they won't break our use case but I see this as redundant, if other cores disagree then meh | 19:38 |
| nibalizer | thats easy to do and helps some prety normal use cases | 19:38 |
| clarkb | nibalizer: no you are missing m point | 19:38 |
| clarkb | its circumventing *the* use case | 19:38 |
| mmedvede | clarkb: I thought that if being able to pass the revision with parameter does not introduce any regressions for Infra, should not be a big deal. But in any case, we can use the other way if that change introduces too much complexity | 19:39 |
| clarkb | mmedvede: its less about the complexity for me and more about the redundancy | 19:39 |
| clarkb | its redundant and unnecessary and there are 3! changes to make it work | 19:39 |
| nibalizer | so the whole point of ref locking and not just using master is because of race conditions where services would be on different versions right? | 19:43 |
| nibalizer | and infra ran for years before it hit the scale where it needed to handle that, so isn't it reasonable to say that a 3rd party ci service wouldn't need it until the needed it? | 19:44 |
| clarkb | yes they should use master | 19:45 |
| clarkb | project-config is set up to do that | 19:45 |
| mmedvede | clarkb: I kind of like redundancy :). I also think that in general, any time we can pass 'repo_url', we should also be able to pass revision. | 19:45 |
| clarkb | you can... | 19:45 |
| fungi | i wouldn't say we ran for years before we needed it. we ran for a while and then by the time we noticed it was a problem it took us quite a while to untangle | 19:46 |
| asselin | nibalizer, what's the status of https://review.openstack.org/#/c/199321/2? recheck it? | 19:46 |
| fungi | plenty of the time where we were running without it, we'd have been a lot better off if it were already in place but the getting there took more work then it would have if we'd started out with that separation to begin with | 19:47 |
| fungi | so having it available from the outset means others can potentially avoid the pain of having to migrate | 19:48 |
| nibalizer | asselin: pabelanger and I are debugging in -infra | 19:48 |
| nibalizer | well, he's debugging and I am standing around being loud | 19:48 |
| asselin | ok | 19:49 |
| anteaya | nibalizer: as long as you know your role | 19:49 |
| *** jesusaurus has joined #openstack-sprint | 19:51 | |
| nibalizer | okay I think I have a solution that will make everyone happy | 19:52 |
| nibalizer | we can put a custom function in openstackci that returns a project-config ref | 19:52 |
| nibalizer | well no that doesnt work either | 19:52 |
| * nibalizer gives up | 19:52 | |
| asselin | I think we can put this on hold for now. It's not needed for setting up 3rd party ci as there are quite a few alternatives available | 19:53 |
| asselin | yolanda, you around, I'd like to start testing nodepool changes | 19:55 |
| asselin | jesusaurus, ^^ | 19:55 |
| asselin | nibalizer, review this? I think we can merge it now https://review.openstack.org/#/c/184919/ | 19:57 |
| asselin | actually just saw anteaya's comments...will look first | 19:58 |
| mmedvede | asselin: +1 on putting project-config patch on hold | 19:58 |
| asselin | zaro, see anteaya's comment on https://review.openstack.org/#/c/184919/ | 20:01 |
| jesusaurus | asselin: what kind of nodepool tests? | 20:01 |
| asselin | jesusaurus, just downloading patches and making sure it works | 20:02 |
| *** Roguehorse has joined #openstack-sprint | 20:02 | |
| jesusaurus | ah, ok | 20:02 |
| asselin | jesusaurus, yolanda any reason why the secure.conf isn't a yaml file? | 20:07 |
| jesusaurus | I just commented on that, I can't think of a reason to use ini instead of sticking with yaml | 20:08 |
| jeblair | we usually use ini files for credentials | 20:09 |
| jeblair | at least, until clouds.yaml :) | 20:09 |
| jesusaurus | jeblair: whats the reason for that convention? | 20:10 |
| jeblair | but for files that are supposed to be simple password stores, it can be simpler, and a good reminder that it's a different file | 20:10 |
| jesusaurus | I suppose the mental reminder that they are separate is a good enough reason for me | 20:11 |
| asselin | Seems like a big change to switch it to yaml, so it would be good to agree | 20:11 |
| jesusaurus | yeah | 20:12 |
| * asselin tests assuming it won't change | 20:12 | |
| asselin | jesusaurus, we also need the puppet-openstackci nodepool changes. Do you want to do those? | 20:13 |
| jeblair | nibalizer: what's the status of beaker rspec tests? | 20:15 |
| jeblair | (or anyone ^) | 20:15 |
| jeblair | maybe i should look at the stack starting here? https://review.openstack.org/184891 | 20:16 |
| asselin | jeblair, I don't think we're looking at those as part of the sprint | 20:17 |
| jeblair | i think we should, otherwise we have no testing? | 20:18 |
| jesusaurus | asselin: which openstackci changes? do they have the downstream-puppet topic? | 20:18 |
| crinkle | jeblair: yes i think that is the place to start reviewing | 20:19 |
| asselin | jeblair, I've been manually testing | 20:19 |
| asselin | jesusaurus, the nodepool ones don't exist yet | 20:20 |
| nibalizer | jeblair: needs some fixups | 20:20 |
| anteaya | can we outline what patches/repos are in scope for the sprint? | 20:20 |
| anteaya | perhaps on the etherpad? | 20:20 |
| jesusaurus | asselin: ah, ok | 20:20 |
| jeblair | asselin: yeah, we'll go a lot faster if we have the robots do it for us | 20:20 |
| nibalizer | I'm looking at repairing the apply test | 20:20 |
| asselin | jesusaurus, basically this: https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/nodepool_prod.pp | 20:20 |
| asselin | jeblair, you're welcome to help us go faster :) | 20:20 |
| nibalizer | but we're quite close on the beaker-rspec testing and openstack/puppet-* already landed their version of it I believe | 20:20 |
| jeblair | asselin: that's what im doing. that's why i'm going to focus on testing. | 20:21 |
| crinkle | yep | 20:21 |
| jeblair | nibalizer: that's separate from the rspec thing? | 20:21 |
| asselin | anteaya, I put some patches on the etherpad | 20:21 |
| anteaya | asselin: thank you | 20:21 |
| nibalizer | jeblair: parse error | 20:21 |
| * anteaya looks at the etherpad | 20:21 | |
| jeblair | nibalizer: you mean your work repairing the apply test is separate from getting rspec going? | 20:21 |
| nibalizer | it is separate yes | 20:22 |
| jeblair | nibalizer: what happened to the apply test? | 20:22 |
| pleia2 | I see much facter fact fun | 20:22 |
| nibalizer | jeblair: there is scrollback in -infra for that right now, when we applied that change I made to make the apply-test easier to read, it removed the output of the test when the test fails | 20:23 |
| nibalizer | if this line fails http://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/apply-test.sh#n105, the following lines aren't executed because of set -e so we get no feedback on what failed | 20:23 |
| jeblair | nibalizer: got it. let me know if you need a review on that; meanwhile, i'll look at the rspec stuff and see if we can get that landed | 20:23 |
| anteaya | it has been a while since I looked at our erb files, I take it we don't indent them at all? | 20:24 |
| jeblair | pleia2: if you have a sec for https://review.openstack.org/198442 that would be swell | 20:25 |
| nibalizer | jeblair: yes I'd appreciate a review of https://review.openstack.org/#/c/199726/ | 20:25 |
| jeblair | anteaya: depends on the underlying file they are writing; erb files are just templates of something else | 20:25 |
| anteaya | true | 20:25 |
| anteaya | I'm used to seeing them indented is all | 20:25 |
| asselin | jesusaurus, please see my comment here: https://review.openstack.org/#/c/188325/ | 20:25 |
| anteaya | guess we don't care | 20:25 |
| nibalizer | and pabelanger has made https://review.openstack.org/199727 which will help as well | 20:25 |
| pleia2 | jeblair: sure, looking | 20:26 |
| pabelanger | _should_ work | 20:26 |
| pabelanger | it is un tested | 20:26 |
| nibalizer | anteaya: the erb rule is 'whatever the actual file wants' so if the file is sendmail.cnf.erb then the indentation should be in sendmail.cnf syntax | 20:26 |
| pabelanger | would be nice to get an jenkins root user to login to a job and confirm | 20:26 |
| jeblair | nibalizer: -1 | 20:26 |
| pabelanger | or something just do a code review :) | 20:26 |
| jeblair | nibalizer: on https://review.openstack.org/199726 | 20:26 |
| nibalizer | ok looking | 20:26 |
| anteaya | nibalizer: okay | 20:27 |
| nibalizer | jeblair: oh :( I thought I was being clever | 20:27 |
| nibalizer | well, we can just revert my change that caused this problem... | 20:27 |
| pabelanger | nibalizer, well, a publish would work | 20:27 |
| jeblair | we really try to limit those to actual publishers | 20:27 |
| pabelanger | right | 20:27 |
| pabelanger | if we could get the swift upload with logs working | 20:28 |
| jeblair | because otherwise, we're encoding job functionality based on jenkins features that may not be available to us in the future | 20:28 |
| nibalizer | pabelanger: my worry about the publish is it is going to create ~40 files called 'applytest\d' and one would have to click each individually and scan through it to find out where the error is | 20:28 |
| pabelanger | then I think the cat stuff could just be nuked | 20:28 |
| pabelanger | nibalizer, yes, there is that | 20:28 |
| jeblair | pabelanger: oh, i see, i thought you were suggesting a post-build task. forget i said anything. :) | 20:28 |
| jesusaurus | asselin: yeah, I see the change that needs to be made, I'll work on writing that | 20:29 |
| asselin | thanks | 20:29 |
| jeblair | nibalizer, pabelanger: we may just need to put a conditional in the apply test job | 20:29 |
| nibalizer | jeblair: pabelanger https://review.openstack.org/#/c/199729/ | 20:29 |
| nibalizer | jeblair: what conditional logic would work? | 20:30 |
| jeblair | nibalizer: https://review.openstack.org/#/c/199729/ wfm | 20:30 |
| nibalizer | ya, I can come through later and get that working right | 20:30 |
| pabelanger | I had https://review.openstack.org/#/c/199713/ up too | 20:30 |
| jeblair | nibalizer: remove -e; res=$?; print some stuff; exit $res | 20:30 |
| pabelanger | but we can revert if people want | 20:30 |
| nibalizer | jeblair: yea I was wondering if that was your suggestion | 20:30 |
| jeblair | pabelanger: why remove -P $(nproc)? | 20:31 |
| nibalizer | okay there are three solutions on the table then. which should we do? | 20:31 |
| pabelanger | jeblair, I was testing parallel puppet for something else | 20:31 |
| pabelanger | red haring | 20:31 |
| jeblair | pabelanger: does that mean your change has an error, or the current state of the repo has an error? | 20:31 |
| pabelanger | Not sure, I was seeing some weirdness on puppet-apply-trusty, way trying to kill 2 birds with that commit | 20:32 |
| pabelanger | but, clarkb and nibalizer assure me -P $(nproc) was not the issue | 20:32 |
| jeblair | oh, test_puppet_apply.sh already has some ret=$? stuff | 20:32 |
| jeblair | pabelanger: left comments on https://review.openstack.org/199713 | 20:33 |
| nibalizer | yes, it uses that to save it and push it back into the find | 20:33 |
| pabelanger | ok | 20:33 |
| jeblair | nibalizer: will the approach in https://review.openstack.org/199713 fix it? | 20:34 |
| jeblair | (modulo the comments i left there) | 20:34 |
| pabelanger | Going to eat with family and chill for a few hours, but plan to be back later tonight to continue hacking. Want to make a dent in the puppet-httpd stuff, even though it is not on this sprint | 20:34 |
| pleia2 | pabelanger: enjoy | 20:34 |
| jeblair | i favor these solutions in order: https://review.openstack.org/199713 or https://review.openstack.org/#/c/199729/ | 20:35 |
| nibalizer | jeblair I think so | 20:36 |
| nibalizer | 199713 i think is go, after fixups | 20:37 |
| jeblair | pleia2: https://review.openstack.org/199713 | 20:37 |
| pleia2 | jeblair: on it, had just pulled it up a moment ago | 20:37 |
| jeblair | has a new rev | 20:37 |
| pleia2 | thanks | 20:38 |
| pabelanger | ya, that should get most of what we need | 20:38 |
| pabelanger | but still an issue I think with it | 20:38 |
| pabelanger | either way, heading out the door | 20:39 |
| pabelanger | will be back | 20:39 |
| pleia2 | so we're doing away with 199729? | 20:39 |
| jeblair | yeah, i think if we land https://review.openstack.org/199713 we can abandon https://review.openstack.org/#/c/199729/ | 20:39 |
| nibalizer | okay will abandon | 20:39 |
| pleia2 | 199713 lgtm | 20:40 |
| jeblair | aprvd | 20:40 |
| jeblair | nibalizer: https://review.openstack.org/184905 looks good with crinkle's changes | 20:46 |
| nibalizer | jeblair: okay will update | 20:47 |
| anteaya | this is the beaker boilerplate patch to puppet-openstackci, quite the lineup of happy reviewers anyone in the mood to give it a push? https://review.openstack.org/#/c/184891/ | 20:47 |
| anteaya | no idea if this is part of this sprint or not | 20:47 |
| anteaya | but it feels right to me | 20:48 |
| jeblair | anteaya: it's what i'm working on with nibalizer now | 20:48 |
| jeblair | i think we can merge it and get working beaker tests for openstackci, which will be great | 20:48 |
| jeblair | (once the change after it lands) | 20:48 |
| nibalizer | ya 184891 can go while i fix | 20:48 |
| nibalizer | the other one, 184905 | 20:48 |
| * zaro is back | 20:49 | |
| jeblair | bombs away | 20:49 |
| anteaya | jeblair: sorry | 20:49 |
| zaro | anteaya, asselin : https://review.openstack.org/#/c/184919/9/manifests/jenkins_job_builder.pp | 20:49 |
| jeblair | anteaya: no need to apologize! | 20:49 |
| jeblair | nibalizer: and when you're done, the change after it needs updating -- because it is _correctly_ failing :) https://review.openstack.org/198463 | 20:49 |
| anteaya | jeblair: okay | 20:49 |
| anteaya | zaro: I don't care what the name is, I'm in favour of consistentcy and also differenciating from jenkins code with concievably an operator would also be dealing with | 20:50 |
| asselin | zaro, personally I like jjb b/c it's shorter and looks more different from jenkins | 20:51 |
| anteaya | which concievabley an operator would also be dealing with | 20:51 |
| asselin | anteaya, +1 consistency is important | 20:51 |
| nibalizer | jeblair: both updated | 20:52 |
| zaro | asselin: maybe all should begin with jjb_* ? | 20:53 |
| anteaya | I am fine with that myself | 20:53 |
| asselin | zaro, perhaps... | 20:53 |
| asselin | zaro, I agree with jenkins_jobs_username --> jenkins_username | 20:55 |
| asselin | similarly for the few below it. | 20:55 |
| asselin | only these two should be jjb: jenkins_git_revision jenkins_git_url | 20:56 |
| asselin | anyone know how to setup this? https://review.openstack.org/#/c/188325/14/templates/secure.conf.erb | 20:57 |
| anteaya | are the variables with jenkins_ in them (without job or jobs) actually referring to jenkins code or variables? | 20:57 |
| asselin | jenkins_masters => [??], | 20:57 |
| asselin | anteaya, mostly the running jenkins service | 20:59 |
| anteaya | okay | 20:59 |
| asselin | this one is wat off jenkins_git_url = 'https://git.openstack.org/openstack-infra/jenkins-job-builder', | 20:59 |
| anteaya | as long as it is clear what is jenkins and what is jjb | 20:59 |
| asselin | anteaya, +1 | 20:59 |
| anteaya | yes that looks like jjb code to me | 20:59 |
| jeblair | asselin, yolanda: hrm, we need a system-config change to start using https://review.openstack.org/188325 | 20:59 |
| asselin | jeblair, yes, jesusaurus ^^ | 21:00 |
| pleia2 | I thought there was one somewhere, let me see | 21:00 |
| pleia2 | nope, just the nodepool one | 21:00 |
| jeblair | asselin: at any rate, i think it would be something like jenkins_masters => [ { name => 'jenkins01', user => '...'}, { name => 'jenkins02', ...} ] | 21:01 |
| asselin | jeblair, ok will give it a shot | 21:01 |
| jeblair | asselin: system-config/modules/openstack_project/manifests/gerrit.pp has a similar data structure | 21:02 |
| jesusaurus | asselin: jeblair: I just pushed up https://review.openstack.org/199737 | 21:05 |
| asselin | getting close to 200000 | 21:05 |
| jesusaurus | jeblair: I don't think we should be managing secure.conf in ::nodepool, it should be in openstack_project::nodepool | 21:05 |
| *** rfolco has quit IRC | 21:05 | |
| jeblair | jesusaurus: shouldn't the puppet nodepool module know how to write its config file? | 21:06 |
| nibalizer | jeblair: this is my argument a lot of the time | 21:06 |
| nibalizer | but the project-config stuff means a lot of these modules don't know how to do that so.... | 21:06 |
| nibalizer | I'm not exactly sure which direction to go | 21:06 |
| jesusaurus | jeblair: currently the nodepool.yaml config file is managed in o_p::nodepool, so why would we put the secure config file in ::nodepool? | 21:06 |
| jeblair | nibalizer: once you start looking at 'project-config' as content that the system runs, it gets a little easier, though not perfect. | 21:06 |
| jeblair | jesusaurus: that's probably just because it hasn't moved into the puppet module yet :) | 21:07 |
| nibalizer | jeblair: ya, zuul's layout.yaml is more like food for zuul not the zuul configuration file, kinda | 21:07 |
| jeblair | nibalizer: right, and the new nodepool.yaml (sans creds) is more like food for nodepool; wheras the stuff in secure.conf is tied to the actual systems running it | 21:07 |
| clarkb | its config for the project not for the service | 21:08 |
| nibalizer | I think there is general consensus that the nodepool.yaml should move out of o_p | 21:08 |
| jeblair | right | 21:08 |
| jeblair | nibalizer: yes, moving creds out of nodepool.yaml means nodepool.yaml can move to project-config | 21:08 |
| nibalizer | also the puppet-os_client_config stuff is under review now if people have time to look. let me update the topic. https://review.openstack.org/#/c/199674/2 | 21:08 |
| nibalizer | so secure.yaml + clouds.yaml allow nodepool.yaml to go to project-config, I think I have that right | 21:09 |
| jeblair | jesusaurus: don't we need to add in user and api keys for each jenkins master in https://review.openstack.org/199737 ? | 21:09 |
| jeblair | nibalizer: yep (well, secure.conf) | 21:09 |
| jesusaurus | jeblair: those values are already being passed in and are the same for all the masters | 21:10 |
| jeblair | jesusaurus: yeah, but in https://review.openstack.org/188325 it switches to allowing per-master values, expecting them to be in each list element | 21:11 |
| jesusaurus | most of the data is already there, which is why i think that's the best place to start managing the new config file | 21:11 |
| zaro | anteaya, asselin : ok, renamed. hope it meets your approval | 21:11 |
| anteaya | zaro: on lines 26,27,28 why not have the key match the value name? | 21:12 |
| jesusaurus | jeblair: 199737 doesnt depend on 188325, its an alternative place to manage the file | 21:12 |
| anteaya | zaro: I'm in agreement up until there | 21:12 |
| jesusaurus | but if others feel strongly about managing secure.conf in puppet-nodepool, then I can change that to depend on 188325 and pass in all the values | 21:13 |
| zaro | anteaya: it's because job_builder.pp has different keys for those. to make your suggestion work i would need to change job_builder.pp in openstack-infra/jenkins | 21:14 |
| asselin | anteaya, those are the argument names for ::jenkins::job_builder and can't be changed | 21:14 |
| asselin | right, what zaro said | 21:14 |
| nibalizer | ya I think moving that into puppet-nodepool is the way to go | 21:15 |
| jeblair | jesusaurus, nibalizer: ++ | 21:15 |
| anteaya | zaro asselin ah okay, thanks | 21:15 |
| anteaya | yes no need to do that | 21:16 |
| anteaya | zaro: thank you | 21:16 |
| jesusaurus | nibalizer: jeblair, alright i'll make that change | 21:20 |
| zaro | asselin: i'm wondering if it would make sense to move openstack-infra/puppet-jenkins/manifest/job_builder.pp to it's own puppet-jjb repo? there's no reason why it needs to be coupled in puppet-jenkins | 21:27 |
| asselin | zaro, perhaps, but save it for another day | 21:27 |
| asselin | zaro, remember to update https://review.openstack.org/#/c/199335/ | 21:28 |
| zaro | haha, full plate huh? | 21:29 |
| asselin | nibalizer, lgtm https://review.openstack.org/#/c/199335/ | 21:29 |
| jeblair | nibalizer: https://review.openstack.org/199743 | 21:31 |
| jeblair | crinkle: ^ | 21:31 |
| nibalizer | asselin: failing tests? | 21:32 |
| zaro | asselin: done, thanks for the reminder | 21:32 |
| * asselin looks...passed my tests | 21:33 | |
| *** TravT has quit IRC | 21:33 | |
| asselin | nibalizer, wrong link: https://review.openstack.org/#/c/184919/ still waiting for jenkins though | 21:34 |
| jeblair | nibalizer, crinkle: though i wonder if it would be more meaningful to s/beaker/rspec/ in that job name | 21:34 |
| nibalizer | i end up just shortening it to beaker | 21:35 |
| nibalizer | i've never dealt with pure beaker so beaker-rspec is just beaker to me | 21:35 |
| jeblair | ok, my brain doesn't have a pattern imprinted yet, so we'll go with yours | 21:35 |
| asselin | zaro, hold on.... | 21:36 |
| asselin | I'm looking here and don't see the point of doing this: https://review.openstack.org/#/c/199335/3/modules/openstack_project/manifests/jenkins.pp | 21:36 |
| crinkle | jeblair: i'm not sure i understand the change, how is it different than the 'gate-{name}-puppet-beaker-rspec-dsvm-{ostype}' jobs? | 21:37 |
| asselin | zaro, why not just keep it as ::jenkins::job_builder and use it directly? | 21:38 |
| jeblair | crinkle: it's very similar, except that regardless of the git repo under test, it clones/checks out puppet-openstackci and runs its beaker rspec tests. so on a proposed change to puppet-zuul, it runs puppet-openstackci beaker rspec. same for a change to system-config. | 21:39 |
| jesusaurus | asselin: nibalizer: jeblair: https://review.openstack.org/199737 | 21:39 |
| *** TravT has joined #openstack-sprint | 21:39 | |
| jeblair | crinkle: puppet-openstackci's beaker rspec, in turn, clones system-config and puppet-zuul, etc, so the change under test is still present in the test. | 21:39 |
| jeblair | crinkle: but all repos participating in the integration test run the exact same thing from the same starting point | 21:40 |
| zaro | asselin: i messed up, another patch coming. | 21:40 |
| nibalizer | so this prevents us from merging something to puppet-nodepool that breaks puppet-openstackci? | 21:40 |
| crinkle | jeblair: ooh this sounds cool | 21:41 |
| jeblair | jesusaurus: cool -- one thing inline -- i think we want to leave the old parameters for a bit while we transition to the new file | 21:41 |
| jeblair | nibalizer: exactly | 21:42 |
| *** TravT has quit IRC | 21:42 | |
| zaro | asselin: sorry about that, got confused. i think updated patch is much better. | 21:42 |
| crinkle | jeblair: nibalizer what's the difference between a 'devstack-{ostype}' node and a 'bare-{ostype}' node? | 21:43 |
| zaro | asselin: i thought we wanted to redirect and use the manifests in openstack-ci, no? | 21:46 |
| jeblair | crinkle: hopefully less as time goes on; but in general, 'devstack' nodes have _fewer_ packages installed than 'bare' (!) and have more things cached (such as cirros images) | 21:47 |
| asselin | zaro, generally yes, but jjb seems like there's not much to do finally.... | 21:47 |
| asselin | zaro, just another level of indirection | 21:48 |
| jeblair | crinkle: i thought i'd see if it would work with a bare node first, thinking perhaps the puppet module jobs were correcting the nodes for things that the openstack puppet modules would need | 21:48 |
| nibalizer | jeblair: for 199743 why don't we have to attach the gate-openstackci-beaker tests to each puppet module in projects.yaml or at least put it in check jobs | 21:48 |
| crinkle | jeblair: ah okay, i was just curious why it was different from the 'gate-{name}-puppet-beaker-rspec-dsvm-{ostype}' jobs | 21:49 |
| jeblair | nibalizer: since it's a single job that does not vary based on what repo it runs on, we only need one instance of it in jenkins. so i attached it to the openstackci project itself (that's kind of an arbitrary choice). | 21:49 |
| jeblair | nibalizer: (it's an arbitrary choice because we don't use {name} anywhere in the template expansion, so you could attach it to any project to instantiate it; so it simply becomes a file organization question) | 21:50 |
| asselin | nibalizer, jeblair jesusaurus seems we can ax the openstack ci JJB changes actually...and just use ::jenkins::job_builder directly. https://review.openstack.org/#/c/199335/4/modules/openstack_project/manifests/jenkins.pp | 21:50 |
| nibalizer | ohhhh | 21:52 |
| jeblair | asselin: i would imagine that the end state for us would be that system-config uses openstackci which uses jenkins::job_builder, right? | 21:52 |
| *** jkomg has joined #openstack-sprint | 21:52 | |
| jeblair | asselin: (in system-config we say "create an openstackci::jenkins server", and openstackci::jenkins uses jenkins::server and jenkins::job_builder to do that) | 21:54 |
| asselin | jeblair, that's not what's going on in this case | 21:54 |
| jeblair | asselin: right | 21:55 |
| jeblair | asselin: my first question is do i have, generally speaking, the right idea in my description of what we're working toward? and if so, my second question is, how do you want to get there? | 21:56 |
| nibalizer | jeblair: I think you have the right idea | 21:57 |
| asselin | perhaps the JJB portion lines 58-EOF need to move into openstackci::jenkins_maste, otherwise, it can be part of the last task (3rd party sample site.pp) that brings everthing together | 21:57 |
| asselin | jeblair, the goal is to be able to setup 3rd party ci re-using the same scripts as infra's ci | 21:58 |
| nibalizer | it is true that we might end up with some puppet modules that are so good that we don't have to perform site-local configuration and o_p::jenkins becomes just 'include openstackci::jenkins' | 21:58 |
| jeblair | asselin: yes, i think that move you describe would do it | 21:58 |
| jeblair | nibalizer: something to work toward. :) | 21:58 |
| jeblair | i'd like to get rid of o_p eventually. or as much of it as possible | 21:59 |
| jeblair | certainly for the more resuable parts of the system. maybe things like o_p::static stick around because "governance.o.o" isn't really a service anyone else will run. | 22:00 |
| nibalizer | groups.o.o, asterisk.o.o yea | 22:00 |
| jeblair | oh, i'm sure someone will reuse those at some point :) | 22:00 |
| asselin | ok, so openstackci::jenkins_master will also setup JJB | 22:01 |
| nibalizer | also Im glad that 'allow-local-ssh-root' got codified into a builder | 22:04 |
| jeblair | pleia2, fungi, clarkb, mordred: would you please review https://review.openstack.org/199743 and its _critical_ parent if you get a min | 22:04 |
| zaro | asselin: you gonna work on that? need help there? | 22:05 |
| * pleia2 reviews | 22:05 | |
| fungi | jeblair: sure thing, looking now | 22:05 |
| nibalizer | so I'm back to wondering why we're using bare-trusty for openstackci beaker tests and dvsm nodes for the other tests | 22:05 |
| pleia2 | -critical- parent | 22:05 |
| jesusaurus | jeblair: asselin: 199737 has been updated | 22:06 |
| jeblair | nibalizer: i tend to only use devstack nodes for devstack jobs? | 22:06 |
| jeblair | if there's a reason, no big deal to switch. i just can't remember one right now | 22:07 |
| jeblair | (and soon they'll be the same anyway) | 22:07 |
| *** TravT has joined #openstack-sprint | 22:07 | |
| nibalizer | thats good enough for me | 22:07 |
| nibalizer | just calling out the difference | 22:08 |
| fungi | nibalizer: i believe the devstack nodes were being used because they had less preinstalled | 22:08 |
| nibalizer | i had thought that we were converging | 22:08 |
| nibalizer | so s'all good | 22:08 |
| fungi | nibalizer: jeblair: i think the direction with https://review.openstack.org/199364 should make us all happy in that regard | 22:08 |
| asselin | zaro, you can do it..I'm looking at nodepool stuff now. Otherwise I can do it next | 22:09 |
| fungi | that's the proof-of-concept extension to consuming bindep in jobs with a fallback for projects with no bindep list | 22:09 |
| jeblair | fungi: ++ | 22:09 |
| zaro | asselin: ok. i'll start it. | 22:10 |
| fungi | i've already basically hand-confirmed that works for nova unit tests on our new minimal ubuntu-trusty nodes | 22:10 |
| fungi | but want to get some more representative timing datto be able to show that the increase in runtime is negligible | 22:10 |
| fungi | datto is apparently a contraction of "data to" | 22:11 |
| fungi | nibalizer: i _think_ the reason to use bare-whatever for now is that we have bare-centos6 but no devstack-centos6 | 22:11 |
| fungi | though i do have "centos-6" nodes working which should be equivalent to a "devstack-centos6" except that we don't expect devstack to actually work on them | 22:12 |
| fungi | however the bare-{ostype} simplification won't work there if we need to select between devstack-precise, devstack-trusty and centos-6 | 22:13 |
| jeblair | asselin, nibalizer: do we still want to go with the approach of having openstackci::jenkins_job_builder, and then just have openstackci::jenkins use it? or instead move all of the code in https://review.openstack.org/184919 into openstackci::jenkins? | 22:18 |
| asselin | zaro, ^^ | 22:19 |
| zaro | i'm not sure why jjb is a special case here? i think it should even have it's own puppet-jjb repo to decouple it from jenkins. | 22:21 |
| zaro | seems like we should stick with the same pattern as we do for the rest of em. | 22:22 |
| asselin | I try to think of it as "what is an openstackci jenkins master?" | 22:23 |
| jeblair | zaro: i do think that we should have puppet-jjb. however, i think openstackci should include jjb in its openstackci::jenkins; i think that's one of the complexities of the system we can hide from people | 22:23 |
| jeblair | because, as asselin says, "an openstackci jenkins master" runs jjb | 22:24 |
| asselin | So in this case is JJB a separate component, or a part of jenkins | 22:24 |
| zaro | well wouldn't it confuse people if we don't stick to a consistent pattern? | 22:24 |
| zaro | but i do undestand the rational. | 22:25 |
| jeblair | here's what i think the end state is: puppet-jenkins-job-builder exists and is used for configuring and running jjb. openstackci::jenkins uses that to run jjb. but users of openstackci never have to see that it's doing that for them. | 22:25 |
| jeblair | so people wanting to use jjb on its own can run puppet-jenkins-job-builder | 22:26 |
| jeblair | and consumers of "openstackci" get it automatically | 22:26 |
| asselin | jeblair, +1 | 22:26 |
| jeblair | which brings us back to https://review.openstack.org/184919 where we are exposing it as openstackci::jenkins_job_builder. i don't think that's necessary, because i don't think it needs to be part of the public API for openstackci. but if we want to do that for our own purposes related to organizing code in openstackci, i think that's fine. | 22:27 |
| jeblair | nibalizer, crinkle: have an opinion on how to handle that case ^ (internal class that we don't expect module users to invoke)? | 22:28 |
| asselin | jeblair, why is this even optional? https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/jenkins.pp#n53 | 22:28 |
| nibalizer | i think openstackci::jenkins should take care of jjb | 22:29 |
| jeblair | asselin: that's a good question | 22:29 |
| jeblair | nibalizer: do you think we should just take the code in https://review.openstack.org/184919 and plop it into openstackci::jenkins_master ? | 22:30 |
| zaro | i'm thinking that option was for jenkins-dev? | 22:30 |
| crinkle | jeblair: https://github.com/puppetlabs/puppetlabs-stdlib#assert_private ? | 22:31 |
| jeblair | zaro, asselin: yeah, it was to facilitate some kind of transition: https://review.openstack.org/14403 | 22:32 |
| crinkle | jeblair: also a big # PRIVATE CLASS DO NOT USE DIRECTLY gets the message across | 22:32 |
| nibalizer | jeblair: either that or mark it as private and include it with openstackci::jenkins_master | 22:32 |
| jeblair | that's a 5 digit change number ;) | 22:32 |
| asselin | well we might need it to migrate over | 22:33 |
| jeblair | asselin: maybe? but i don't think we've used it in a loooooong time :) | 22:33 |
| jeblair | i think it can go a way | 22:34 |
| asselin | I'm leaning towards including it in openstackci:jenkins_master. A JJB class doesn't do much. | 22:35 |
| jeblair | asselin: i have a slight preference for that too (though would be okay with the other if there's a compelling argument). i'll -1 with that suggestion | 22:36 |
| asselin | and openstackci:jenkins_master isn't very complicated as it is | 22:37 |
| zaro | ok, are we settled? | 22:37 |
| jeblair | zaro, asselin: i think so; check out my comment on https://review.openstack.org/184919 | 22:38 |
| zaro | cool. i'll continue working on the move to jenkins_master manifest. | 22:41 |
| asselin | zaro, add my comment as well | 22:41 |
| asselin | btw, I think this is a good reason to also to the system-config changes. Even if they don't merge, it certainly helps to sence check our work. | 22:42 |
| asselin | also do* | 22:43 |
| nibalizer | I'm about to head out for the day, any particular patches people want my eyes on? | 23:04 |
| nibalizer | topic:downstream-puppet seems pretty reviewed at this point | 23:04 |
| jhesketh | Morning, how's the sprint going? :-) | 23:05 |
| asselin | jhesketh, making progess...lots of good discussions going on | 23:06 |
| jhesketh | asselin: great :-) | 23:09 |
| asselin | i'm testing the nodepool changes | 23:10 |
| asselin | current issue...not sure if it's code or config yet: http://paste.openstack.org/show/356600/ | 23:11 |
| asselin | read the manual....it's config | 23:13 |
| asselin | no idea. jesusaurus can you help out with this? ^^ | 23:21 |
| jesusaurus | asselin: taking a look now | 23:22 |
| jesusaurus | asselin: what does your secure.conf look like? | 23:24 |
| jesusaurus | does it have a local-jenkins section? | 23:25 |
| asselin | http://paste.openstack.org/show/356691/ | 23:25 |
| asselin | maybe - vs _? | 23:25 |
| asselin | yup....sorry about that... | 23:26 |
| asselin | but thanks...saw the error in your question | 23:26 |
| jesusaurus | yeah, it also looks nodepool wants "local-jenkins" to be in double quotes | 23:27 |
| asselin | ok good b/c it still doesn't work | 23:27 |
| asselin | added quotes and got past that error | 23:28 |
| jesusaurus | I noticed the quotes at line 1434 in https://review.openstack.org/#/c/189762/10/nodepool/nodepool.py | 23:29 |
| asselin | I might have removed them while trying to tinker with it | 23:30 |
| anteaya | jhesketh: we weren't rechecking that any more until the puppet-apply test was fixed, is it fixed? | 23:30 |
| anteaya | perhaps it happened and I missed the blessed event | 23:31 |
| jhesketh | ah, sorry, I didn't realise it was properly broken | 23:31 |
| anteaya | good and proper | 23:31 |
| jhesketh | righto, I'll hold off then | 23:31 |
| anteaya | any of the apply test yes | 23:31 |
| anteaya | till we get the all clear | 23:31 |
| anteaya | and thanks | 23:31 |
| jhesketh | thanks for the heads up | 23:33 |
| anteaya | sure | 23:33 |
| *** TravT has quit IRC | 23:48 | |
| asselin | mmedvede hows logstash going? | 23:53 |
| asselin | zaro, how's your stuff going? | 23:53 |
| mmedvede | asselin: Almost ready to push first patch with logstash and friends for openstackci module | 23:53 |
| *** jkomg has quit IRC | 23:54 | |
| asselin | mmedvede, cool, looking forward to try it out | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!