19:00:43 <jeblair> #startmeeting infra 19:00:44 <openstack> Meeting started Tue Mar 31 19:00:43 2015 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:47 <pcrews> o/ 19:00:48 <openstack> The meeting name has been set to 'infra' 19:00:48 <jeblair> #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:00:48 <jeblair> #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-24-19.00.html 19:00:52 <jeblair> #topic Actions from last meeting 19:00:52 <ianw> o/ 19:00:56 <jeblair> anteaya cause a problem statement and requirements regarding election tooling to be sent to the infra list so various solutions can be discussed 19:00:56 <jeblair> #link https://etherpad.openstack.org/p/XU4qRouXIH 19:01:11 <jeblair> anteaya: thanks for that 19:01:13 <GheRivero> o/ 19:01:16 <anteaya> welcome 19:01:22 <tristanC> Hello! 19:01:26 <zaro> o/ 19:01:28 <krtaylor> o/ 19:01:35 <jeblair> anteaya: i think you are expecting some input on that. and i think i promised to give you some. 19:01:38 <anteaya> so unless we have some more edtis to that or any objections I'll send that out this afternoon 19:01:46 <anteaya> jeblair: you mentioned it yes 19:01:47 <jeblair> so i should do that before then, then. :) 19:01:57 <anteaya> jeblair: thanks, that would be most welcome, thank you 19:02:27 <anteaya> and tristanC not sure if you have had a chance to review the etherpad yet 19:02:36 <anteaya> tristanC: let me know what you think 19:02:37 <jeblair> and anyone else, pitch in soon. i think the point was to try to make the requirements clear so we can effectively propose and evaluate solutions 19:02:44 <anteaya> yes 19:02:53 <jeblair> clarkb make sure bandersnatch is being updated 19:02:53 <jeblair> #link https://review.openstack.org/#/c/167382/ 19:03:02 <clarkb> anteaya: don't forget to clean up my comment about self editing 19:03:09 <anteaya> clarkb: will do 19:03:30 <jeblair> clarkb: did a thing^ yay! :) 19:03:40 <jeblair> i think that's self-explanator 19:03:41 <jeblair> y 19:03:43 <clarkb> I did, it just needs another +2 then either I can approve or someone else 19:03:47 <jeblair> fungi send announcement email for renames 19:03:47 <jeblair> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059948.html 19:03:51 <fungi> happened 19:03:55 <jeblair> fungi did that and more! 19:03:58 <fungi> and how 19:04:00 <jeblair> jeblair document openstack id deployment mechanism in http://ci.openstack.org/openstackid.html 19:04:00 <jeblair> #action jeblair document openstack id deployment mechanism in http://ci.openstack.org/openstackid.html 19:04:05 <jeblair> jeblair did not do that thing 19:04:06 <jeblair> :( 19:04:11 <asselin_> o/ 19:04:15 <anteaya> that is okay, we have this week 19:04:18 <jeblair> #topic Schedule next project renames 19:04:48 <jeblair> so there's murano; no further communication on that change 19:04:52 <jeblair> are any murano people around? 19:04:52 <fungi> if someone comes up with a bit more time to test the utf8 conversion, we could consider doing it along with the murano move 19:05:06 <mordred> ++ 19:05:26 <jeblair> zaro: are you still working on that? 19:05:30 <clarkb> also did we get the xstatic package rename correct and the fallout yesterday was unrelated to the new name? 19:05:37 <fungi> serg_mel seems to not be in here 19:05:42 <jeblair> clarkb: we got it correct. someone deleted the old name from pypi. 19:05:44 <clarkb> aiui that is the case but may be worth following up on to make sure that doesn't need more changes 19:05:49 <zaro> jeblair: sorry i dropped the ball on that. will do it this week. 19:05:52 <clarkb> jeblair: gotcha 19:05:53 <jeblair> zaro: np 19:06:24 <jeblair> okay, we'll wait for the murano folks to re-engage 19:06:37 <anteaya> clarkb: as fungi explained to me we have no control over someone deleting a package from pypi that is in global requirements 19:06:51 <fungi> other than to ask them to please put it back 19:06:54 <clarkb> anteaya: yup I was worried that we didn't get the rename correct 19:06:56 <jeblair> i don't think anyone knows what's going on with gantt yet. 19:06:58 <fungi> or to stop depending on it 19:07:12 <jeblair> i don't actually know the motivation for the gantt discussion? 19:07:13 <anteaya> clarkb: yup 19:07:21 <jeblair> is it just cleaning up the openstack namespace? 19:07:27 <fungi> yes 19:07:31 <anteaya> jeblair: yes it appears to be 19:07:42 <anteaya> andereas likes things in order 19:07:45 <jeblair> if so, i'd prefer to just let it sit until someone decides to either do something with it or that nothing will ever be done with it 19:07:49 <bauzas> hey 19:07:54 <mordred> jeblair: ++ 19:07:55 <bauzas> \o 19:07:58 <fungi> "it's a seemingly abandoned effort in an ostensibly official repo namespace" seems to be the entirety of the concern 19:07:59 <jeblair> it seems like folks are saying 'this might still happen in the future' 19:08:01 <anteaya> jeblair: I agree 19:08:09 * mordred has submitted a patch to gantt to delete all the files 19:08:11 <mordred> fwiw 19:08:22 <bauzas> mordred: and I +2'd it 19:08:25 <mordred> bauzas: woot! 19:08:26 <jeblair> mordred: that should provide more data :) 19:08:38 <anteaya> there is a thread on the mailing list about what to call the effort so they can't yet agree on naming 19:08:42 <mordred> oh - it failed the docs job 19:08:48 <bauzas> so yeah, agreed on the plan to clean up the repo 19:09:02 <bauzas> mordred: saw that, probably needs a recheck 19:09:05 <jeblair> bauzas: are you okay leaving it there for now until there's a plan to move forward? 19:09:13 <fungi> anteaya: well, i think that's more around avoiding using the gantt name to refer to other activities related to scheduler decomposition 19:09:21 <bauzas> jeblair: I like mordred's idea to clean up 19:09:31 <bauzas> jeblair: and keep it as it is 19:09:32 <anteaya> fungi: okay well in any case, there is lack of agreement 19:09:40 <jeblair> ok. 19:09:45 <bauzas> fungi: I sent an email about that 19:09:50 <fungi> yep, i read it 19:10:14 * fungi probably spends too much time trying to read a lot of what crosses the -dev ml 19:10:22 <bauzas> http://lists.openstack.org/pipermail/openstack-dev/2015-March/060179.html 19:10:25 <jeblair> #agreed merge mordred's change to delete all content from gantt repo, but otherwise, leave as-is until there is a more substantive plan to move forward with the effort or it is truly abandoned 19:10:33 <jeblair> anyone disagree with that ^ ? 19:10:38 * fungi agrees 19:10:46 * anteaya has no problem with that 19:10:48 <clarkb> sounds like a plan to me 19:10:49 <jesusaurus> o/ 19:10:51 <bauzas> I also have to check with the Foundation about the legals for the codename 19:10:52 <bauzas> +1 19:10:54 <jeblair> (i can undo it if we do, fwiw) 19:11:15 <jeblair> cool, sounds like we're okay then, and there are no pending project renames 19:11:22 <jeblair> bauzas: thanks! :) 19:11:34 <jeblair> #topic Priority Efforts (Swift logs) 19:11:34 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:enable_swift,n,z 19:12:03 <jeblair> looks like the footer changes are still outstanding and could use a review 19:12:12 <clarkb> jeblair: we are waiting on your response to jhesketh at https://review.openstack.org/#/c/167158/2 19:12:22 <clarkb> jeblair: I think the footer changes all have the necessary +2s though 19:12:22 <jeblair> i think jhesketh is back from leave so we can progress there 19:12:48 <jeblair> cool, will review 19:12:59 <jeblair> #topic Priority Efforts (Nodepool DIB) 19:12:59 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:dib-nodepool,n,z 19:13:04 <jeblair> mordred: have your etherpad link handy? 19:13:08 <mordred> yeah - one sec 19:13:17 <jeblair> #link https://etherpad.openstack.org/p/dib-nodepool-merges 19:13:18 <jeblair> found it 19:13:21 <mordred> https://etherpad.openstack.org/p/dib-nodepool-merges 19:13:23 <mordred> oh 19:13:40 <mordred> so - this is pretty darned near close 19:13:52 <mordred> all of the pieces now exist, pending code review and bug finding 19:14:01 <jeblair> and the etherpad provides some nice narrative structure so we can see how it will all fall in to place 19:14:32 <mordred> given the nature of the thing, it still make take a week or two to finish landing, as some of these changes we'll want to watch 19:14:50 <mordred> and as clarkb has pointed out, we'll need to test that devstack runs properly on the -minimal based images 19:15:28 <mordred> but I think we'd have to do that if we modifed the cloud images to remove cloud-init as well, because $unknown_knockon_effects 19:15:40 <mordred> but we're quite close 19:15:46 <jeblair> mordred: i reviewed all the infra changes in there yesterday, i can probably do another pass to catch updates today or tomorrow 19:15:56 <mordred> jeblair: I've rebased a few things since then 19:16:19 <clarkb> I am trying to review the related changes and get my nodepool changes for multiple image types up to par 19:16:34 <mordred> clarkb: we shoudl add that change to the etherpad 19:16:39 <jeblair> i think it's there 19:16:40 <mordred> if we haven't already 19:16:42 <mordred> cool 19:17:07 <clarkb> yup I added it 19:17:12 <jeblair> anything else to talk about here? 19:17:14 <yolanda> so it will be affecting in some way to that: https://etherpad.openstack.org/p/Nodepool_benchmarks . Shall i add this to that etherpad as well? 19:17:23 <fungi> working through comparing the results of 164447 on various devstack-.* sample nodes from our providers and comparing the result to the equivalent bare-.* samples 19:17:44 <fungi> oh, we were going to briefly bikeshed on new-world-order platform identifiers 19:17:48 <mordred> oh yeah 19:18:12 <mordred> I'd like to suggestion we name our things $distro-$release once there is no bare/trusty distinction 19:18:14 <clarkb> we could do ubuntu14.04-timestamp and centos7-timestamp 19:18:18 <jeblair> yolanda: i think they are separate efforts 19:18:26 <mordred> clarkb: I'd say trusty not 14.04 19:18:29 <fungi> since we don't have an equivalent devstack-centos6 worker to move bare-centos6 jobs onto, i need to make something. best not to call it "devstack-centos6" since we won't likely run devstack on it 19:19:05 <mordred> basically, I don't thin kwe should have things named centos6 and centos7 if we don't also have ubuntutrusty 19:19:13 <mordred> it's a small bikeshed 19:19:19 <fungi> and because i patterned dib's release/version support on the idea i could match it to our node labels, i'll want to tweak that too if we want to use something different than we do now 19:19:30 <mordred> and then I think because ubuntutrusty looks weird, we should add a - 19:19:39 <fungi> er, s/dib/bindep/ 19:19:48 <mordred> so centos-7, centos-6, ubuntu-trusty, fedora-21 19:19:55 <fungi> though dib also has something similar apparently. so converging our identifier format would be good, i think 19:20:19 <jeblair> what's the dib thing that is similar? 19:20:24 <greghaynes> that maps to DIB's $DISTRO_NAME-$DIB_RELEASE, 19:20:26 <fungi> anyway, if there are no objections to mordred's proposal, i'll go with centos-6 as the new node label 19:20:42 <greghaynes> the list mordred wrote maps to that 19:20:44 * anteaya doesn't object 19:20:46 <jeblair> greghaynes: does that match what mordred is sugg... 19:20:49 <jeblair> cool :) 19:21:08 <jeblair> clarkb: okay with $distro-$release? 19:21:11 <mordred> ok - now what color trusty do we want? 19:21:11 <clarkb> jeblair: sure 19:21:13 <greghaynes> theres a caveat with centos7 actually, but thats a dib bug 19:21:19 <clarkb> I only suggested numbers for consistency ut I don't care 19:21:27 <mordred> greghaynes: and it's fine with the centos-minimal element :) 19:21:29 <fungi> with the expectation that we'll do ubuntu-something as well (i don't care if we mix release codenames and version numbers personally) 19:21:35 <clarkb> its all going to get grepped and sed'd the same either way 19:21:50 <jeblair> mordred: numbers or names? 19:21:56 <mordred> I think trusty is the common form for ubuntu, and 7 is the common for centos 19:21:58 <mordred> so I think we shoudl use those 19:22:06 <mordred> if we have debian images, I think we shoudl use names too 19:22:16 <jeblair> mordred: and numbers for fedora? 19:22:21 <mordred> because I _CERTAINLY_ have no idea what number jessieis 19:22:22 <fungi> yeah, it's more that centos just doesn't have good release names 19:22:22 <jeblair> cause fedora does have names 19:22:23 <mordred> jeblair: yes 19:22:36 <mordred> I don't hear people use them as much - but I could be very wrong about that 19:22:43 <greghaynes> DIB is all name based fwiw 19:22:56 <fungi> greghaynes: what does dib call centos 6 and 7? 19:22:57 <greghaynes> er, no 19:23:00 <jeblair> greghaynes: so it uses fedora-beefy-miracle? 19:23:05 <mordred> so ... fedora uses numbesr for fedora-minimal 19:23:08 * fungi loves that name 19:23:11 <greghaynes> thats wrong, yea ;) its name based for ubuntu, number for everything else 19:23:12 <mordred> you have to pass in 21 to $DIB_RELEASE 19:23:19 <mordred> otherwise the chroot building will not work 19:23:20 <greghaynes> but we can incorporate beefy-miracle 19:23:28 <mordred> it really has to do with mirror paths 19:23:41 <fungi> so maybe "gravitate toward current dib behavior, whatever that is" is what we're suggesting? 19:23:47 <mordred> we cannot, sadly, use beefy-miracle 19:23:59 <jeblair> #agreed use $distro-$release (eg 'ubuntu-trusty', and 'fedora-21') for image names, matching usage in dib where possible 19:24:03 <jeblair> look good ^ ? 19:24:04 <mordred> jeblair: ++ 19:24:05 <ianw> we don't use the names for fedora, but then they use things like "Schrödinger" which introduces other types of fun 19:24:07 <greghaynes> jeblair: ++ 19:24:17 <fungi> great! thanks for suffering through the bikeshed 19:24:29 <mordred> fungi: should we paint our trusty purple? 19:24:38 <jeblair> #topic Priority Efforts (Migration to Zanata) 19:24:38 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:zanata,n,z 19:25:07 <cinerama> oh hi there 19:25:12 <jeblair> are the changes ready for widespread review now? 19:25:33 <clarkb> I have reviewed a few of them and I would say they are ready 19:25:36 <cinerama> jeblair: so we landed the base change. i think we can start reviewing and landing what i've got up on the board now 19:25:53 <cinerama> i've also reviewed stevenk's fine work on the client 19:25:55 <clarkb> cinerama: oh that merged, awesome 19:26:13 <cinerama> and now i'm doing some testing with that to see what we'll need to add to it. 19:26:14 <jeblair> cool; should we, oh, spin up a server? 19:26:30 <cinerama> jeblair: bit nervous there 19:27:01 <cinerama> jeblair: but i think we're close. i'd like to test a couple more things here 19:27:09 <jeblair> cinerama: cool, no prob 19:27:14 <cinerama> maybe before EOW or early next week tho 19:27:46 <anteaya> cinerama: if you say yes now it will probably take that long anyway 19:27:58 <cinerama> anteaya: hey that's a good point 19:28:11 <jeblair> also we should see if pleia2 wants to do most of the work there 19:28:17 <anteaya> never turn down teh offer of a server 19:28:32 <cinerama> anteaya (& others) this is my first rodeo so any advice is really helpful 19:28:34 <fungi> i'm happy to volunteer to try and boot a server running that when you're satisfied that it's time 19:28:47 <anteaya> cinerama: it is dev only anyway 19:28:54 <anteaya> not much can go wrong 19:28:58 <fungi> and feed you details on whatever puppet errors end up preventing it, if any 19:29:30 <jeblair> fungi: (psst, volunteer to backup pleia2 booting a server so she can gain xp) 19:29:34 <cinerama> jeblair: yeah i was thinking for pairing & stuff waiting for pleia2 before we set up might be good 19:29:45 <fungi> or help pleia2 through it, yes! i missed that comment above ;) 19:30:01 <jeblair> she's out for a bit, right? will she be back next week? 19:30:23 * fungi didn't pay close attention to when she said she was getting back 19:30:39 <anteaya> yes next week 19:30:52 <jeblair> so that will probably work with cinerama's timetable anyway 19:31:00 <anteaya> and she has been wanting a server for some time 19:31:00 <cinerama> that sounds good 19:31:05 <anteaya> fwiw 19:31:18 <jeblair> anything else? 19:31:34 <jeblair> #topic Priority Efforts (Downstream Puppet) 19:31:35 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:downstream-puppet,n,z 19:32:04 <yolanda> from my side, i couldn't progress so much there but there are some changes with pending reviews, and some others i answered the reviews 19:32:17 <asselin_> I have log server puppet scripts refactored and waiting on reviews 19:32:33 <nibalizer> nothing from me 19:32:42 <yolanda> everything with topic downstream-puppet from my side 19:32:48 <anteaya> asselin_: I said I would review and didn't sorry about that 19:33:13 <jeblair> cool, plenty of stuff to review this week :) 19:33:18 <jeblair> #topic Priority Efforts (Askbot migration) 19:33:18 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:askbot-site,n,z 19:33:21 <mordred> yay reviewing 19:33:49 <jeblair> the pgsql module should be accepted into governance today and we can create that 19:34:33 <jeblair> i think that's the big thing here, right? anything else? 19:34:53 <fungi> oh, right, mrmartin is unavailable today 19:35:10 <fungi> yeah, once we get that created, we can move forward safely 19:35:19 <fungi> we could in theory move forward without it and add it later 19:35:22 <clarkb> the solr stuff got in right? so indexing is working 19:35:40 <fungi> reed sent an e-mail to the -community ml about scheduling the cut-over 19:35:44 * fungi finds a link 19:36:01 <reed> fungi, thanks 19:36:32 <fungi> #link http://lists.openstack.org/pipermail/community/2015-March/001102.html 19:36:43 <jeblair> did reed just drop off? 19:36:49 <fungi> seems so 19:36:53 <jeblair> bad timing :( 19:37:16 <mordred> maybe san francisco got hit by an comet 19:37:18 <anteaya> april 6 is easter monday 19:37:18 <fungi> anyway, the migration steps in the spec are confirmed working from my initial test, so the maintenance should be brief 19:37:51 <fungi> i loosely timed all the steps and should be able to finish within half an hour 19:38:07 <jeblair> is that date set? 19:38:12 <anteaya> fungi: how many people to do the work, just one or a group? 19:38:34 <fungi> anteaya: i can do the maintenance steps since i've already done them once 19:38:49 <clarkb> fungi: when you set up the dev instance? 19:38:55 <fungi> just one person, plus some people to do usage tests to make sure it's still doing what it is supposed to 19:39:10 <jeblair> i expect i'll be around then to pitch in if needed 19:39:18 <jeblair> monday is an interesting choice though 19:39:20 <anteaya> fungi: so I guess it is up to you, when do you want to do it? 19:39:25 <fungi> clarkb: it's not a dev instance, it's the new server, we just haven't switched dns over pending a second database dump 19:39:32 <clarkb> fungi: gotcha 19:39:51 <clarkb> My only monday restriction is I have to afk about 6pm PDT 19:39:52 <anteaya> I see 2 choices on the linked email 19:39:53 <clarkb> which should be fine 19:40:21 <fungi> yeah, reed what was the motivation for monday? because a lot of people won't be trying to use it on a common international holiday? 19:41:05 <jeblair> if those are the choices, i think we should go with monday so that we can land the puppet changes beforehand 19:41:11 <fungi> i'm guessing it was more that he looked at browser analytics to find weekly low-points in traffic volume 19:41:28 <anteaya> I can be around to help test 19:41:55 <anteaya> so monday? 19:42:12 <fungi> wfm 19:42:13 <jeblair> #info ask.o.o migration probably happening on Monday April 6th, 10am PDT 19:42:16 <jeblair> :) 19:42:23 <jeblair> #topic Puppet Testing 19:42:23 <jeblair> #link https://review.openstack.org/#/c/164908/ 19:42:26 <fungi> i'll follow up to the ml thread 19:42:31 <jeblair> oops 19:42:34 <jeblair> #topic Priority Efforts (Upgrading Gerrit) 19:42:34 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:gerrit-upgrade,n,z 19:42:46 <reed> fungi, because monday is the first available day for me 19:43:06 <fungi> reed: oh, okay great! 19:43:09 <reed> fridays are bad at doing complex things, if they fail the weekend is damaged :) 19:43:16 <jeblair> so we're waiting on utf8 testing 19:43:33 <jeblair> are we still targeting 2.9, or is it worth looking at 2.10 yet? 19:43:53 <jeblair> i believe we have > 1 month, so even that should be doable 19:43:56 <anteaya> zaro: are you about? 19:44:02 <clarkb> 2.11 is already in rc 19:44:03 <zaro> yes 19:44:13 <clarkb> so it may be good to 2.10 if nothing bad comes up in testing just to get us closer? 19:44:15 <anteaya> zaro: 2.10? thoughts? 19:44:26 <mordred> 2.10 may get us WIP plugin, yeah? 19:44:42 <zaro> no. it won't 19:44:56 <zaro> i'm fine with trying 2.10 19:45:13 <jeblair> #action zaro to continue utf8 testing 19:45:30 <jeblair> #action zaro test gerrit 2.10 19:45:41 <jeblair> zaro: what does wip plugin need? 19:46:00 <anteaya> zaro: I'd like close connection functionality whichever one we select 19:46:03 <zaro> uhmm, lots of stuff i think. 19:46:14 <zaro> REST endpoints don't seem to work 19:46:33 <jeblair> wip plugin requires >=2.11 according to http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-02-10-19.01.html 19:46:38 <zaro> some core stuff needs to get approved as well. still sitting in review 19:47:20 <zaro> i took yesterday to test it more deeply and entered some issues in to the gerrit issue tracker. 19:47:36 <jeblair> zaro: what's 'it' ^ ? 19:47:46 <zaro> https://code.google.com/p/gerrit/issues/list?can=2&q=WIP+plugin 19:47:52 <jeblair> ah, wip plugin 19:48:02 <jeblair> zaro: anything else we should be working on? 19:48:26 <zaro> one change would ike to merge soon is 19:49:08 <zaro> https://review.openstack.org/#/c/155448/ 19:49:55 <zaro> otherwise just reviews on gerrit-upgrade topic 19:50:02 <jeblair> zaro: thanks! 19:50:04 <jeblair> #topic Zuul layout split using (tristanC) 19:50:04 <jeblair> #link https://review.openstack.org/#/c/152290/ 19:50:07 <jeblair> tristanC: around? 19:50:12 <tristanC> yes! 19:50:22 <clarkb> zaro: is that change in 2.10? 19:50:31 <zaro> which one? 19:50:33 <jeblair> tristanC: you have a change to implement that! :) 19:50:33 <tristanC> so well, the spec is up for review since sometime already... 19:50:47 <clarkb> zaro: 155448 19:50:49 <zaro> clarkb: ohh, not sure. i can check 19:50:56 <jeblair> tristanC: yeah the spec merged: http://specs.openstack.org/openstack-infra/infra-specs/specs/zuul_split.html 19:51:35 <jeblair> tristanC: i want to try to let jhesketh's connection changes land soon 19:51:53 <tristanC> and I experiment with a split of openstack current layout here: https://review.openstack.org/#/c/163243/ 19:52:02 <jeblair> tristanC: it's getting close and the rebases for that are becoming troublesome 19:52:34 <jeblair> tristanC: would it be okay to defer merging this until after that merges? 19:52:58 <tristanC> jeblair: it should be easy to refactor/rebase though, not sure about the design though... I put the code in the layoutvalidator and it could be somewhere more meaningfull 19:53:36 <jeblair> tristanC: okay, i'll try to review it before then to give you some feedback while we wait 19:53:47 <tristanC> jeblair: that would be awesome :) 19:53:57 <jeblair> #topic Puppet Testing 19:53:58 <jeblair> #link https://review.openstack.org/#/c/164908/ 19:54:20 <jeblair> so there's a proposed change that added some puppet rspec tests to one of our puppet modules 19:54:34 <jeblair> and it struck some of us as being unecessary 19:54:47 <jeblair> i wonder if we can articulate a policy on puppet testing 19:54:52 <anteaya> rspec is a whole ruby testing framework 19:54:59 <clarkb> in particular about half of the tests essentially rewrite the module 19:55:06 <jeblair> clarkb: indeed 19:55:07 <anteaya> which if you are doing a lot of ruby is worthwhile 19:55:08 <clarkb> which to me is redundant and does not add much value 19:55:25 <anteaya> my sense of the crowd is you will find rspec more effort that is is worth 19:55:34 <jeblair> i'm much more interested in functional tests; the puppet apply tests are really useful i think 19:55:50 <jeblair> and since we have nodes with sudo, i bet we can do more 19:55:59 <yolanda> i find that tests useful, but it's quite hard to find real problems there and discriminate from the others 19:56:09 <fungi> yeah, "will this break" is more helpful to me than "is this right" 19:56:25 <jeblair> yolanda: absolutely. but problems do cause it to fail at least. it's kept _so many_ things from breaking production 19:57:00 <jeblair> so i wonder if we could functionally test each module on a node? 19:57:04 <yolanda> i know, i'd like if some efforts can be dedicated to cleanup the error logs there. Some are just warnings , or incorrect settings 19:57:23 <jeblair> have a simple manifest that uses the module and runs for real on a node? 19:57:28 <clarkb> jeblair: we could probably ship a tiny site.pp/node def for each module and run that then do specific sanity cheks 19:57:33 <clarkb> jeblair: ya that 19:57:36 <fungi> yolanda: i fear that most of those errors are entirely because of running with --noop 19:57:44 <yolanda> jeblair, i'm doing sort of a thing with vagrant actually 19:57:44 <jeblair> fungi: i think you may be right 19:57:51 <nibalizer> ++ to func tests 19:57:59 <tchaypo> When I've looked at puppet-rspec before, my sense has always been that it's not worth the hassle - it's a whole nother language to learn and seems to largely result in you having to write your change twice in unrelated languages 19:58:05 <zaro> clarkb: yes, https://review.openstack.org/#/c/155448/ is in gerrit stable-2.10 branch. 19:58:06 <clarkb> jeblair: I like the idea, it should be simple and help us determine where the boundary between openstack_project and everything else is 19:58:14 <anteaya> tchaypo: yes, that is rspec 19:58:27 <clarkb> jeblair: then test that interface 19:58:27 <tchaypo> Other people I know have used them successfully but they spent a lot more time writing ruby/puppet than I did 19:58:28 <yolanda> so the changes i write, are tested functionally on a node, we could do something like that but using nodepool 19:58:30 <jeblair> so is there an existing pattern/framework for "run a simple manifest and do some checks"? should we just write a manifest, and use something like envassert after it runs? 19:58:33 <anteaya> it is written for tdd 19:58:34 <mordred> anteaya: I agree - it seems like more hassle than it's worth 19:58:41 <anteaya> mordred: for us, oh yes 19:58:44 <anteaya> we don't tdd 19:58:45 <mordred> for us. yes 19:58:47 <nibalizer> my concern is do we want to spend 60 nodes per change to anything 19:58:52 <mordred> well, not in that way 19:58:54 <tchaypo> I get the feeling they're useful for people who spend a lot of time writing puppet but they raise the barrier for entry 19:59:00 <mordred> tchaypo: ++ 19:59:02 <clarkb> nibalizer: just one 19:59:04 <jeblair> nibalizer: we could do this just on the modules 19:59:21 <clarkb> jeblair: right, we would test the interfaces modules expose individually 19:59:22 <fungi> right, functional test, not integration test 19:59:27 <clarkb> instead of the entire thing composed together 19:59:27 <jeblair> nibalizer: so a puppet-httpd change would consume one node to run the single test to test the httpd module 19:59:41 <nibalizer> ya okay 19:59:41 <mordred> ++ 19:59:42 <jeblair> nibalizer: and we would not run these on the system-config repo 19:59:49 <nibalizer> im super down for this 19:59:54 <jeblair> reserving the puppet apply as the 'integration' test 20:00:07 <jeblair> nibalizer: want to hack out a POC for one of the modules? 20:00:08 <nibalizer> i took the gerrit module out the other day and it was rough using it standalone without prebuilt hiera 20:00:12 <nibalizer> jeblair: yea its on my list 20:00:16 <nibalizer> im thinking envassert 20:00:23 <nibalizer> or beaker but :sigh: 20:00:25 <anteaya> oh look at the time 20:00:26 <jeblair> cool. i'll leave the feedback on 164908 about not wanting rspec 20:00:30 <jeblair> thanks everyone! 20:00:33 <jeblair> #endmeeting