19:00:24 <jeblair> #startmeeting infra
19:00:25 <openstack> Meeting started Tue Mar 24 19:00:24 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:28 <yolanda> o/
19:00:29 <openstack> The meeting name has been set to 'infra'
19:00:31 <anteaya> never enough meetings
19:00:32 <jeblair> #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:00:32 <jeblair> #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-17-19.01.html
19:00:38 <jeblair> this is going to be a very fast-paced meeting today
19:00:43 <jeblair> #topic Schedule next project renames
19:00:52 <jeblair> we have some to do now, i believe
19:00:55 <jeblair> at least bindep
19:00:58 <anteaya> yes
19:01:01 <notnownikki> o/
19:01:05 <SpamapS> o/
19:01:10 <jeblair> is gnocchi ready to go too?
19:01:11 <clarkb> and gnocchi
19:01:12 <greghaynes> O/
19:01:15 <timrc> o/
19:01:19 <timrc> Howdy.
19:01:19 <fungi> i'm around friday and saturday, whenever everyone else wants it done
19:01:20 <jhesketh> Morning
19:01:21 <mrmartin> o/
19:01:23 <petertr7> Hello
19:01:23 <clarkb> jeblair: I think so, they have a change up to reflect the post rename state
19:01:27 <asselin> o/
19:01:33 <jeblair> how about let's do the renames this friday?
19:01:37 <fungi> wfm
19:01:44 <mordred> o/
19:01:45 <anteaya> me too
19:01:45 <fungi> 1900utc? later?
19:01:47 <TheJulia> o/
19:01:47 <pcrews> o/
19:01:56 <cody-somerville> \o_
19:02:15 <cinerama> party time in meeting city
19:02:24 <zehicle> o/
19:02:26 <jeblair> would 2100 or 2200 be okay?
19:02:30 <anteaya> sure
19:02:39 <ianw> o/
19:02:40 <fungi> yep, that's fine for me too
19:02:41 <anteaya> either is fine with me
19:02:42 <krtaylor> o/
19:03:03 * SergeyLukjanov hereo/
19:03:04 <jeblair> #agreed next renames 2200 utc friday mar 27
19:03:18 <jeblair> someone want to send an email?
19:03:21 <fungi> i can
19:03:28 <jeblair> #action fungi send announcement email for renames
19:03:38 <fungi> i'll put together a plan etherpad for it too
19:03:38 <jeblair> #topic Priority Efforts
19:03:50 <jeblair> I'm going to try to timebox the priority efforts to just a few minutes each so that we can get to our backlog.  If there are no issues blocking the effort that we need to discuss, let's just move on quickly.
19:03:52 <anteaya> fungi: cool, thanks
19:04:01 <jeblair> #topic Priority Efforts (Swift logs)
19:04:01 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:enable_swift,n,z
19:04:10 <jhesketh> Nothing to discuss afaik, just rolling forward
19:04:19 <jeblair> cool, thanks!
19:04:20 <jeblair> #topic Priority Efforts (Nodepool DIB)
19:04:20 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:dib-nodepool,n,z
19:04:50 <mordred> this has done well
19:04:52 <jeblair> mordred, fungi: anything to discuss?
19:04:52 <clarkb> not much here other than reviewing more tests and the bindep move and shade changes
19:04:56 <mordred> gone
19:04:59 <fungi> the bindep additions still need reviews (infra-core can actually +2 those as of last week), and i have a few more patches to write. no new blockers
19:05:17 <jeblair> ah yeah, i have forgotten to bindep. thanks for the reminder
19:05:18 <anteaya> fungi: does bindep have to be in a certain state before it moves?
19:05:25 <fungi> anteaya: nope
19:05:27 <anteaya> k
19:05:44 <jeblair> #topic Priority Efforts (Migration to Zanata)
19:05:44 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:zanata,n,z
19:05:59 <cinerama> oh hai. so we're making steady progress
19:05:59 <anteaya> pleia2: is away
19:06:06 <anteaya> I think she said just reviews
19:06:10 <clarkb> I just reviewed a stack of zanata related puppet
19:06:18 <clarkb> cinerama: ^ let me know if you have questions about m comments
19:06:18 <fungi> i should do the same
19:06:19 <jeblair> and stevenk has started a patch to install the client via puppet
19:06:26 <cinerama> only thing i really want to flag at the mo is that https://review.openstack.org/#/c/165696/ needs to be deployed prior to us firing up zanata
19:06:39 <fungi> thanks cinerama
19:06:45 <fungi> #link https://review.openstack.org/165696
19:06:54 <jeblair> how do we make sure that's deployed?
19:07:02 <cinerama> (tldr it's a change required for openstackid.org)
19:07:10 <fungi> i think mrmartin/smarcet need to tag a new release
19:07:15 <cinerama> i'm new to this game so i don't know how we do upgradey things
19:07:19 <mrmartin> fungi: am I?
19:07:28 <clarkb> cinerama: we can fire up zanata it just won't let us login right?
19:07:31 <fungi> mrmartin: smarcet i guess?
19:07:32 <jeblair> cinerama: we're all new to openstackid :)
19:07:44 <mrmartin> fungi: I can, if I know what we are releasing
19:08:01 <cinerama> clarkb: yeah that's it. just need to let openstackid recognize a broader range of request strings so the libs zanata uses for openid will work
19:08:08 <fungi> but point being 165696 needs to appear in a tag on that repo so it will get deployed into production
19:08:19 <fungi> presumably it's just on master for now
19:08:24 <jeblair> fungi: do we deploy specific tags, or... what?
19:08:26 <cinerama> no rush since we need the other stuff to be ready first
19:08:37 <cinerama> otoh having it in place earlier won't actually hurt anything
19:09:00 * tchaypo waves
19:09:04 <fungi> jeblair: yeah, production deploys updates on each new tag while teh dev server deploys tip of master if memory serves. is that correct mrmartin?
19:09:21 <mrmartin> correct
19:09:23 <cinerama> that's good to know - so we can just point it at openstackid-dev.o.o for now?
19:09:31 <fungi> cinerama: yes, should work
19:09:35 <jeblair> i wonder how we do that, but i will learn about that on my own time :)
19:09:39 <cinerama> fungi: super
19:09:40 <samueldmq> hi o/ (late, sorry)
19:09:48 <fungi> jeblair: puppet magics
19:10:01 <mrmartin> cinerama: but be careful, because the profile db behind openstackid-dev.o.o can be a bit old
19:10:15 <mrmartin> so it is not sure that your account exists there.
19:10:17 <Rockyg> good info to capture in infra doc...
19:10:30 <jeblair> Rockyg: yeah, i was thinking we should update http://ci.openstack.org/openstackid.html with deployment info
19:10:58 <jeblair> i want to learn about it anyway so...
19:11:05 <zaro> o/
19:11:10 <jeblair> #action jeblair document openstack id deployment mechanism in http://ci.openstack.org/openstackid.html
19:11:17 <fungi> agreed. right now it's comingled with basic documentation of the software itself
19:11:21 <Rockyg> kewl
19:11:26 <mrmartin> if you want to integrate openstackid I suggest to do it with a local dev version first, it is easier to track the logs
19:11:32 <fungi> there is a separate change proposed to get the software documentation added and published for openstackid
19:11:37 <mrmartin> as I know smarcet is working on an integration doc for that.
19:11:40 <jeblair> this was useful :)  anything else on this topic?
19:11:58 <fungi> #link https://review.openstack.org/165199
19:11:59 <cinerama> mrmartin: good thinking there. on my local setup here i have an openstackid server setup
19:12:01 <fungi> for reference
19:12:31 <cinerama> nothing else to report on zanata - i just need to integrate and/or argue about everyone's feedback :)
19:12:41 <jeblair> cinerama: cool, thanks!
19:12:42 <jeblair> #topic Priority Efforts (Downstream Puppet)
19:12:42 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:downstream-puppet,n,z
19:13:10 <anteaya> looks like just reviews required
19:13:15 <nibalizer> yep
19:13:16 <jeblair> anteaya: agreed
19:13:31 <clarkb> so I have been reviewing them and very few actualy have the topic set
19:13:33 <nibalizer> this one keeps needing rebases https://review.openstack.org/#/c/162830/
19:13:39 <yolanda> in the same line, there are pending reviews for puppet-pupet and puppet-bandersnatch
19:13:40 <jeblair> clarkb: oh that'll do it
19:13:43 <clarkb> so would be good if you are workign on related items to use the topic
19:14:02 <anteaya> clarkb: +
19:14:10 <asselin> clarkb, I think you can update the topic
19:14:10 <fungi> puppet-puppet is our latest ouroboros i guess
19:14:14 <clarkb> I think asselin's make puppet-openstackci and nibalizer merge template and base are the only changes I saw there
19:14:26 <jeblair> nibalizer: good point, we should try to land that soon
19:14:32 <anteaya> fungi: openstackci-openstackci is fun one too
19:14:32 <clarkb> asselin: I can, but I am not going to hunt all of these changes down. I am just noticing that in my list of things to review there are very few changes
19:14:47 <asselin> clarkb, ok I see
19:14:48 <jeblair> anteaya: it should be puppet-openstackci
19:15:02 <anteaya> jeblair: that's what I thought too
19:15:04 <clarkb> jeblair: anteaya and the puppetforge name is openstackinfra-openstackci
19:15:19 <asselin> jeblair, clarkb suggested openstackinfra-openstackci
19:15:20 <jeblair> yolanda: set the topics to "downstream-puppet" for the puppet and bandorsnatch changes
19:15:26 <anteaya> #link https://review.openstack.org/#/c/165588/4/metadata.json
19:15:27 <yolanda> ok
19:15:41 <jeblair> yeah, i think our local repos have "puppet-foo" as the name, but they end up as "openstackinfra-foo" on the forge
19:15:43 <clarkb> asselin: anteaya the repo should be puppet-openstackci, the puppetforge name is openstackinfra-openstackci
19:15:49 <yolanda> jeblair, shall i do the same for changes intended to make modules more reusable?
19:15:53 <anteaya> clarkb: ah thank you
19:16:09 <anteaya> clarkb: it is correct now
19:16:29 <asselin> clarkb, what about all the other modules? seems they're all wrong?
19:16:34 <jeblair> yolanda: i think so.
19:16:35 <notnownikki> i can update the topics on the bandersnatch changes, yolanda
19:16:46 <yolanda> k
19:16:53 <clarkb> asselin: yes they need to be updated
19:17:00 <nibalizer> asselin: yep
19:17:16 <jeblair> clarkb, asselin: where are they wrong?
19:17:27 <clarkb> jeblair: in the metadata.json files
19:17:29 <notnownikki> topics changed
19:17:30 <jeblair> ah yeah
19:17:48 <jeblair> so nibalizer and i are working through publishing the httpd module
19:17:55 <nibalizer> jeblair: http://git.openstack.org/cgit/openstack-infra/puppet-logstash/tree/metadata.json#n2 should be openstackinfra
19:18:11 <jeblair> let's finish working through that module before we make metadata changes to the others
19:18:16 <nibalizer> jeblair: ok
19:18:17 <jeblair> in case we find we have more to do
19:18:18 <asselin> fungi, still have your mass update script?
19:18:29 <fungi> asselin: in my head anyway
19:18:36 <anteaya> safe there
19:19:09 <jeblair> anything else on this?
19:19:10 <fungi> there's not much to iterating over a list of projects matching a regex and then running sed -i in each and commiting/pushing via git-review
19:19:21 <anteaya> not from me
19:19:28 <asselin> no
19:19:32 <nibalizer> jeblair: nope
19:19:33 <jeblair> #topic Priority Efforts (Askbot migration)
19:19:34 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:askbot-site,n,z
19:19:42 <mrmartin> ok, so two reviews waiting here
19:19:56 <mrmartin> I found the Chinese solr issue, and there was a missing cron job
19:20:01 <mrmartin> so we are on good track again
19:20:22 <fungi> yeah, evgeny suggested a few additional things for us to check/test during the eval time, so that helped
19:20:27 <fungi> thanks for knocking those out mrmartin
19:20:32 <mrmartin> I guess we need to do add a backup, and as fungi suggested the local backup scripts
19:20:58 <mrmartin> I have only one question here, do we have pgsql-backup for bup similar to mysql-backup?
19:21:00 <jeblair> yeah, we have an existing pattern with mysql dbs where we do a local database backup to disk, then that gets backed up by the system backup
19:21:03 <fungi> aside from the chinese search problem, the rest are non-user-facing so i don't think we need to extend the eval time unless you do
19:21:28 <fungi> mrmartin: if you're asking whether pgsql-backup exists yet, not to my knowledge
19:21:30 <clarkb> mrmartin: you would need to add postgresql specific local backups, but once you have that the bup backups will pick it up
19:21:31 <jeblair> mrmartin: i don't think we have backed up a pg database yet, so we will have to develop some new puppet for that
19:21:48 <jeblair> how's that for triangulating an answer? :)
19:21:55 <anteaya> nice
19:22:00 <clarkb> you can likely use the mysql backup manifest as a good template, just change the command and output file as appropriate
19:22:19 <mrmartin> awesome, so we have two options here, add a simple cron script to backup, or the nice one to create the missing pgsql bup that can be reused later.
19:22:24 <fungi> the basic dump command is already in the migrate spec too
19:22:50 <jeblair> mrmartin: i think our mysql backups actually just add a cron script
19:23:01 <mrmartin> the original ask deployment contains a cron scheduled backup script, so we can reuse that very quickly
19:23:10 <jeblair> oh i see
19:23:13 <mrmartin> and bup will backup those files too
19:23:17 <clarkb> jeblair: yup and logrotate to keep a few iteratons around
19:23:35 <mrmartin> so in case of a restore situation, we have a proper sql dataset.
19:23:40 <fungi> probably the one improvement i'd be interested in seeing to the original script on the current production ask.o.o is to rotate multiple db dumps like we do for mysql
19:23:59 <fungi> but that's not critical to have day 1
19:24:05 <mrmartin> ok, I check the mysql bup too, if it not seems to be too complicated, I do it quickly
19:24:13 <jeblair> mrmartin: sounds like a plan
19:24:32 <jeblair> #topic Priority Efforts (Upgrading Gerrit)
19:24:32 <jeblair> #link https://review.openstack.org/#/q/status:open+topic:gerrit-upgrade,n,z
19:24:49 <fungi> we're on trusty now!
19:24:51 <jeblair> yay we're on trusty! :)
19:24:59 <tchaypo> wooo
19:25:02 <jeblair> next step is "Gerrit 2.9 upgrade Saturday May 9, 2015"
19:25:04 <anteaya> has there been any bugs?
19:25:08 <anteaya> I haven' seen any
19:25:09 <fungi> we still need to dig into why the utf-8 update failed
19:25:15 <anteaya> ah that
19:25:21 <fungi> and possibly retry that on friday
19:25:21 <clarkb> and trusty git doesn't do shallow clones?
19:25:27 <fungi> right, that
19:25:37 <fungi> well, the git-http-backend cgi anyway
19:25:54 <jeblair> so the utf-8 thing needs a bit more planning
19:26:07 <zaro> we can a script to convert tables, ready to go.
19:26:15 <jeblair> it seems it will involve table modifications, so we need to test with the actual production dataset
19:26:46 <zaro> *we can/we have
19:26:55 <jeblair> zaro: can we get you a copy of that for you to work with so you can test it out?
19:27:00 <fungi> can we dump/source it into a new trove instance and then try there?
19:27:10 <fungi> or is going it on a local mysqld fine?
19:27:16 <fungi> er, doing
19:27:30 <jeblair> i think a local mysql and a local gerrit should be fine
19:27:30 <clarkb> considering our mysql instance is mysql 5.1 we probably want something similar?
19:27:48 <clarkb> unsure of how much mysql version affects row data encoding
19:27:49 <zaro> yes, can do
19:28:22 <jeblair> #action zaro test utf8 conversion with production database and local mysql/gerrit 2.8
19:28:42 <jeblair> zaro: i put 2.8 ^ there since we're talking about doing this before the 2.9 upgrade, so we should make sure to test it with the current version
19:28:58 <zaro> sounds good
19:29:05 <anteaya> zaro: the review queue for the patches is just review them, yes?
19:29:07 <fungi> zaro: i can get the database dump to wherever you need it
19:29:18 <jeblair> if that's ready to go by friday, cool; if now, we'll do it the next time -- i don't want to rush it and mess up our data
19:29:28 <anteaya> agreed
19:29:58 <jeblair> zaro: thanks!
19:30:03 <jeblair> #topic Election tooling (tristanC)
19:30:03 <zaro> anteaya: don't understand your question
19:30:18 <anteaya> #link https://etherpad.openstack.org/p/scaling-election-tooling
19:30:19 <fungi> tristanC is on vacation this week i believe
19:30:30 <anteaya> well I wrote the etherpad
19:30:36 <anteaya> so let me know your thoughts
19:30:55 <anteaya> bascially as I explain on the etherpad the current election tooling doesn't scale
19:31:12 <anteaya> and for the sake of both the election officials and the electorate it needs to
19:31:20 <anteaya> this is a proposal to address that need
19:31:44 <anteaya> zaro: was just saying you aren't blocked on any gerrit patches, youjust need reviews to happen
19:32:15 <jeblair> the foundation has a system for nominating people for board elections; i think it would be cool to use that for other elections too
19:32:21 <anteaya> and let's remember that when using an etherpad it is considered friendly to others to put your name in the top right hand corner
19:32:38 <anteaya> jeblair: great, how can we evaluate that system?
19:32:42 <anteaya> jeblair: I dno't know it
19:33:25 <jeblair> anteaya: maybe it's part of the foundation web site?
19:33:31 <anteaya> oh
19:33:45 <anteaya> I'm hesitant to use something we don't have control over in infra
19:33:57 <fungi> so the specific infra items being proposed for discussion: 1. git repos for nomination and platform info, 2. some publication mechanism for the same?
19:34:08 <anteaya> yes
19:34:14 <jeblair> yeah, but i think it's worth acknowledging that there's a need that might be filled by work the foundation has already done
19:34:18 <anteaya> that would be a reasonable tl;dr
19:34:32 <anteaya> okay I'm fine with acknowledging that
19:34:38 <fungi> just making sure we have actual topics to discuss rather than something nebulous
19:34:49 <anteaya> no idea what the next step would be to investigate it
19:34:58 <anteaya> fungi: yes, topics are helpful
19:35:15 <jeblair> fungi: i'm interested in the conversation that lead us to thinking that election nominations via git repo are a solution
19:35:21 <anteaya> the publication mechnisim was let a need and more an extention of using a git repo
19:35:36 <anteaya> well it lead me to thinking
19:35:48 <fungi> jeblair: i missed the conversation myself, only commented on the etherpad after i saw it
19:35:50 <jeblair> it feels like git repos are the only tool we have and i'm wondering is there any other tools in that box over there
19:35:57 <anteaya> since this is the first opportunity it has come beofre any group that could constitute an us
19:36:17 <anteaya> there was no conversation
19:36:19 <jeblair> anteaya: are you open to conversations about other solutions, or do you want only to discuss the mechanics of the proposal in the etherpad?
19:36:33 <anteaya> I took a walk and realized git repos scale, and then wrote the etherpad
19:36:44 <anteaya> oh by all means let's discuss
19:36:49 <fungi> okay, so it's more of a straw man proposal
19:36:53 <anteaya> but it has taken 3 weeks to get a discussion
19:37:04 <fungi> definitely good as a starting point
19:37:05 <anteaya> and this is the only way I figured I could get the space to talk about it
19:37:06 <jeblair> ya, sorry, but we did better today :)
19:37:10 <anteaya> we did
19:37:12 <anteaya> thank you
19:37:18 <anteaya> so yes, discuss away
19:37:27 <anteaya> election officals need to retain their sanity
19:37:41 <anteaya> electorate need confidence in what is going on
19:37:51 <fungi> i agree being able to reuse the nomination system would be cool, since it already has a way to link your foundation profile to your nomination
19:37:55 <anteaya> those are the only two stipulations in the solution
19:37:57 <jeblair> okay, so i've suggested the alternative of trying to adapt the foundation election system to support other elections.  that is not easy because it's not (yet) an open development model and would require some code
19:38:15 <anteaya> we have missed this round anyway
19:38:29 <anteaya> as they had to make a decision to communicate to the electorate
19:38:30 <jeblair> probably talking with foundation folks about the progress of that and what would be involved would be useful
19:38:34 <anteaya> so we have until next fall
19:38:38 <jeblair> may not be much more to say about that here :)
19:38:39 <anteaya> but we do need something
19:38:53 <anteaya> jeblair: fair enough
19:39:00 <anteaya> anyone with any other thoughts?
19:39:08 <anteaya> you are welcome to add them to the etherpad
19:39:08 <clarkb> jeblair: anteaya if we send something to the infra list about that we can poke people to go read it
19:39:15 <anteaya> as a point of communication
19:39:20 <jeblair> clarkb: sounds like a plan
19:39:20 <fungi> so to step back, the specific problem we're trying to address is "it's messy and time consuming to have nominations posted to the ml, confirmed, and platform statements/q&a pasted into a wiki article by a small team of election officials"
19:39:21 <clarkb> and/or we can point at the etherpad if we add the option there
19:39:32 * ianw will not mention storing candidates in a bitcoin side-chain :)
19:39:39 <anteaya> fungi: well it is overwhelming now
19:39:49 <jeblair> ianw: creative! :)
19:39:55 <anteaya> fungi: plus having stackforge use the same process confuses the electorate
19:40:08 <anteaya> as they keep thinking the election has started and they missed it
19:40:22 <jeblair> i keep thinking that too
19:40:29 <anteaya> so the tool needs to be clear to the electorate which are govenered elections and which aren't
19:40:29 <clarkb> anteaya: I don't think your proposed system fixes that though
19:40:33 <fungi> wait, what, we haven't? ;)
19:40:35 <anteaya> clarkb: fair enough
19:40:39 <anteaya> let's do better
19:41:05 <anteaya> and yes
19:41:15 <anteaya> haveing more elections to administer is hard to do
19:41:25 <anteaya> hence the sanity for officials bit
19:41:42 <anteaya> thanks for listening, we can come back to this again
19:41:47 <jeblair> anteaya: i do think the git repo does solve a lot of problems; it may be the most expedient method of scaling this
19:41:51 <anteaya> and yes more ideas and communication welcome
19:41:58 <anteaya> jeblair: that is what I thought
19:42:03 <anteaya> we don't have to build a thing
19:42:07 <anteaya> and git scales
19:42:08 <jeblair> anteaya: i think it will need a lot of details worked out
19:42:15 <anteaya> jeblair: fair enough
19:42:22 <anteaya> acl permissions for one
19:42:25 <fungi> maybe a list of features a solution needs/tasks it should handle is a better place to start (a requirements document of sorts) rather than jumping right into designing something
19:42:34 <clarkb> fungi: +1
19:42:35 <anteaya> sure
19:42:43 <anteaya> I welcome help on doing that
19:42:44 <jeblair> fungi: yes, i think there was some of that in the etherpad, but not organized as such
19:42:54 <anteaya> as I may be too close to the issue to think broadly enough
19:43:07 <jeblair> so let's work on a good problem statement + requirements
19:43:09 <fungi> agreed. possibly with less focus on what we're doing now that doesn't work so well
19:43:14 <anteaya> sure
19:43:35 <jeblair> and then push that to the infra list and follow it up with any broad ideas we have for addressing them
19:43:36 <anteaya> so thanks for the time and support here
19:43:42 <fungi> i mean, those are lessons learned that we need to use when considering solutions, but not necessarily requirements themselves
19:43:50 <anteaya> true
19:43:54 <tchaypo> Linux Australia has a thing called memberdb that I think does most of what we need
19:44:10 <tchaypo> but from memory it’s either a messy pile of perl, or a messy pile of python translated from perl a decade ago
19:44:10 <jhesketh> err, I would not advocate for memberdb
19:44:11 <anteaya> tchaypo: cool, I'd be interested in knowing more
19:44:16 <anteaya> jhesketh: ah okay
19:44:20 <tchaypo> LA themselves are trying to get rid of it :)
19:44:26 <jeblair> yeah, running our own election system is another interesting solution
19:44:27 <anteaya> ha ha ha
19:44:28 <ianw> tchaypo: weren't they looking at getting rid of that?
19:44:28 <jhesketh> well perhaps it's a contender, but it would need serious work
19:44:34 <tchaypo> but it sounds like we have similar sets of requirements..
19:44:38 <anteaya> we don't have to replace condorcet
19:44:43 <anteaya> it is wonderful
19:44:43 <jhesketh> not so much get rid of as upgrade
19:44:47 <anteaya> just the nominations part
19:44:49 <fungi> well, sounds like we might, but getting that fleshed out is really step 1
19:45:01 <tchaypo> let’s shelve that while we investigate git though
19:45:16 <anteaya> to be clear just nominations is what I am looking at
19:45:27 <anteaya> our actual app for running the polls is wonderful
19:45:34 <jhesketh> to be clear, memberdb is horribly broken
19:45:40 <anteaya> jhesketh: ack
19:45:46 <fungi> nominations and position/debate details per candidate sounds like
19:45:47 <tchaypo> I think git should work well for the nominations
19:45:49 <jhesketh> but that's not to say it can't be fixed
19:45:55 <jeblair> anteaya: i know you want help on this, but i'm going to action you to at least continue driving it :)
19:46:00 <tchaypo> we have ability for approvals and such in gerrit
19:46:01 <anteaya> I've taken a lot of time on this and thank you
19:46:06 <anteaya> jeblair: I'm fine driving
19:46:11 <jeblair> anteaya: feel free to interpret this as "anteaya convince someone else to..." :)
19:46:17 <anteaya> but we have seen what I come up with when alone
19:46:22 <anteaya> jeblair: will do
19:46:27 <anteaya> so help welcome
19:46:42 <anteaya> thanks all
19:46:44 <jeblair> #action anteaya cause a problem statement and requirements regarding election tooling to be sent to the infra list so various solutions can be discussed
19:46:55 * anteaya nods
19:47:05 <jeblair> anteaya: and i'll be happy to help with that :)
19:47:10 <anteaya> thank you :)
19:47:18 <jeblair> #topic Update bandersnatch (anteaya)
19:47:22 <anteaya> this is me again
19:47:27 <anteaya> mostly as driver
19:47:47 <anteaya> as you can see in the agenda dsufft gave us a warning to update bandersnatch
19:47:52 <anteaya> I don't know how to do that
19:48:00 <anteaya> but I do know how to copy paste to an agenda
19:48:06 <anteaya> so do we want to do that?
19:48:21 <jeblair> do we CD bandersnatch?
19:48:24 <clarkb> we should, its likely as simple as ensure => latest on our bandersnatch install with puppet
19:48:28 <clarkb> I can look into that
19:48:32 <anteaya> thanks
19:48:46 <jeblair> also, worth checking if we have "-U" on that :)
19:48:59 <anteaya> that's all from me
19:49:06 <jeblair> #action clarkb make sure bandersnatch is being updated
19:49:21 <jeblair> #topic Puppet Style
19:49:22 <fungi> yeah, last time i manually upgraded the 4 servers
19:49:23 <nibalizer> yea iss ensuure => present right now
19:49:37 <jeblair> speaking of =>
19:49:39 <nibalizer> so this https://review.openstack.org/#/c/164819/
19:49:48 <fungi> mainly so that we could downgrade again easily if it turned out to be broken
19:50:06 <fungi> stylish!
19:50:06 <jeblair> i'm inclined to lean toward sticking with the predominant puppet style for the moment
19:50:11 <nibalizer> i think we've got some oppinions there
19:50:17 <jeblair> i don't actually agree with the rules
19:50:40 <jeblair> but i also think we've written some terrible puppet in the past, and we're trying to write some better puppet now
19:50:40 <nibalizer> seems like the infra cores are in agreeent, and the people more heaviliy involved with the greater puppet community are in agreement
19:51:09 <jeblair> and when we go out to tell people that they are doing module versioning wrong, i don't want our lack of arrow alignment to cause them to not take us seriously :)
19:51:11 <clarkb> I think the trouble here is the people doing the review are predominantly the cores
19:51:17 <clarkb> and this is a problem with reviewing code
19:51:28 <anteaya> I think adhereing to community style allows new people from the community to help us, rather than isolating us
19:51:37 <nibalizer> i agree with anteaya
19:51:43 <nibalizer> will infra-cloud puppet live in system-config or outside?
19:51:52 <mordred> nibalizer: stackforge
19:51:58 <clarkb> so you have two camps which fall along lines of how much trouble is this to review
19:51:58 <mordred> nibalizer: we're going to use the stackforge puppet modules
19:52:00 <nibalizer> no i mean the composition layer
19:52:01 <fungi> i definitely don't find aligned columnar whitespace (beyond indentation) to be more readable. quite the contrary. but i'll concede that it's mostly a product of what you spend most of your time staring at
19:52:04 <mordred> nibalizer: oh - that'll be us
19:52:20 <mordred> I don't think the rocketship alignment helps
19:52:22 <mordred> BUT
19:52:24 <mordred> I also don't mind it
19:52:30 <cinerama> it also makes the changes noisy and wastes time
19:52:40 <mordred> it doesn't bother me as much as others in my own brain
19:52:40 <cinerama> but if that's what upstream do then i guess it is good to do it
19:52:53 <nibalizer> lifting the restriction and allowing style to float will create inconsistency and that will be the most gross thing imho
19:52:56 <mordred> so I could be on board with ditching or with keeping
19:52:58 <jeblair> cinerama: what makes changes noisy?
19:53:10 <jeblair> cinerama: (just want to be sure i understand what you're saying)
19:53:11 <nibalizer> lifting the restriction and changing the entire codebase is a huge flurry of changes
19:53:26 <cinerama> jeblair: if one paramenter changes or is added then the spacing must be fixed for every line in that definition
19:53:31 <jeblair> nibalizer: oh yeah, i think we would not change the codebase, just let it drift over time.
19:53:54 <jeblair> cinerama: ah yes, i agree.  that's the very thing that prompted the proposal in fact.
19:54:14 <notnownikki> which is going to get read the most, the diffs or the resulting manifest? I'd go with making the most read one more readable. so I'm for keeping the alignment
19:54:39 <clarkb> thats interesting, I predominantly read diffs :)
19:54:39 <nibalizer> again i feel that I should say that the gerrit ui uses dark/light green to show when a text blob has been changed instead of just moved
19:54:47 <jeblair> notnownikki: i hope the diffs, actually.  :)
19:54:55 <nibalizer> so all the light green text in puppet is colored different than the line that was added/modified
19:54:57 <notnownikki> jeblair, clarkb, but you're core :) we want to attract newbies
19:55:11 <notnownikki> and when we're making modules reusable...
19:55:17 <notnownikki> for downstream consumption
19:55:24 <cinerama> ftr i am not a core and i agree with those folks
19:55:26 <notnownikki> manifest readability matters
19:55:34 <jeblair> nibalizer: yes, so does gertty.  that's just a small part of the issue.  it still requires someone to see and parse that information.
19:55:39 <fungi> whether or not aligned operators is more readable is mostly a matter of personal taste
19:55:39 <ianw> i would say that emacs puppet-mode does by default doesn't seem to work with openstack puppet; it always wants to indent differently.  not sure if the spaces are confusing it but maybe this helps
19:55:45 <pabelanger> FWIW: I do prefer the puppet lint checks
19:56:21 <jeblair> so we do not have consensus now, and there are good arguments on either side
19:56:28 <jeblair> i think we should put this to rest and leave it as is for now.
19:56:35 <mordred> jeblair: ++
19:56:45 <nibalizer> to throw a wet mordred at the probleme, I could go to the place in git where the official puppet style guide is and propose lifting the arrow operator alignment requirement there
19:56:46 <SpamapS> consensus is overrated. ;)
19:57:06 <anteaya> nibalizer: good luck with that
19:57:08 <mordred> wow. I've become a thing someone throws at something now. I suppose I had that coming
19:57:11 <fungi> we might also consider whether it's something we care about for modules published to the forge, but not for system-config
19:57:13 <clarkb> I think it is also worth noting that we don't do everything that pep8 tells us to do
19:57:18 <clarkb> or what hacking tells us to do
19:57:28 <pabelanger> fungi, I would agree with that statement
19:57:34 <anteaya> nibalizer: but I'm in just to see you toss a wet mordred
19:57:34 <clarkb> puppet isn't being signled out as a special thing here, adapting format practices to local needs is common
19:57:36 <jeblair> i may, at some point in the distant future, bring this up again when i believe everyone here has reviewed enough puppet to think like i do.  :)
19:57:37 <mordred> clarkb: we _DO_ do everything pep8 the spec tells us to do
19:57:39 <notnownikki> fungi, yeah i'd go for that
19:57:43 <mordred> clarkb: just not pep8 the overreaching lint tool
19:57:51 <mordred> jeblair: :)
19:58:08 <nibalizer> jeblair: +1 for resting
19:58:16 <jeblair> so does anyone object with keeping the status quo for now in order to achieve maximum average harmony? :)
19:58:17 <fungi> i expect mordred plans to solve this dilemma by replacing it with a bunch of yaml
19:58:28 <anteaya> ha ha ha
19:58:34 <nibalizer> fungi: basically
19:58:34 <mrmartin> :)
19:58:36 <anteaya> + status quo
19:58:40 <clarkb> I am fine with aligned rockets, I have dealt with them for years :)
19:58:41 <jeblair> nibalizer: (and i do like your wet mordred idea ;)
19:58:45 <fungi> i'm in favor of revisiting at a later date
19:59:03 <jeblair> #agreed stick with aligned rockets for now
19:59:17 <mordred> fungi: actually ... in-tree hiera DOES fix large portions of this with yaml
19:59:34 <jeblair> #secretplan wait until more people are reviewing puppet and see the light
19:59:36 <fungi> however it's not applied to system-config at the moment. i assume sticking with the status quo means leaving it not running for that repo
19:59:54 <jeblair> fungi: ha!  how did that happen?
19:59:57 <mordred> fungi: ++ status quo means status quo
20:00:14 <ttx> I see some light
20:00:14 <fungi> jeblair: i think you ragedeleted it at one point, but i'd have to check git log ;)
20:00:21 <anteaya> ttx is that the time?
20:00:26 <jeblair> thanks all :)
20:00:28 <jeblair> #endmeeting