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