19:01:28 <jeblair> #startmeeting infra
19:01:29 <openstack> Meeting started Tue Aug 26 19:01:28 2014 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:33 <openstack> The meeting name has been set to 'infra'
19:01:33 <nibalizer> o/
19:01:36 <jeblair> #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:01:38 <krtaylor> o/
19:01:43 <jeblair> #link last meeting http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-08-19-19.02.html
19:01:45 <jesusaurus> o/
19:01:55 <jeblair> #topic  Actions from last meeting
19:02:01 <jeblair> jeblair Publish python-jenkins 0.3.3 (last release without pbr) tarball to pypi
19:02:03 <jeblair> that happened
19:02:07 <zaro> o/
19:02:09 <jeblair> so did 0.3.4
19:02:09 <anteaya> yay
19:02:15 <jeblair> because 0.3.3 was broken
19:02:19 <anteaya> :(
19:02:32 <fungi> if there were no broken releases we'd never have new releases ;)
19:02:38 <anteaya> ha ha ha
19:02:47 <jesusaurus> heh, true
19:02:50 <jeblair> but now i think that's all taken care of, and the next (0.4.0?) release can be done by zaro by pushing a tag in the normal way
19:03:12 <ianw> o/
19:03:19 <jeblair> pleia2 create new mailing lists
19:03:20 <zaro> i think that will happen in about a month.
19:03:34 <pleia2> that was done, anteaya will talk about it later in the meeting
19:03:40 <jeblair> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/third-party-announce
19:03:41 <anteaya> I can talk now
19:03:45 <jeblair> pleia2: i reordered :)
19:03:48 <anteaya> they are up
19:03:50 <pleia2> oh good :)
19:03:51 <anteaya> thanks pleia2
19:03:59 <jeblair> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/third-party-request
19:04:07 <anteaya> this is my first time admining lists, feedback welcome
19:04:07 <krtaylor> yea!
19:04:10 <jeblair> #link https://review.openstack.org/#/c/116989
19:04:26 <anteaya> and that is the patch to redirect folks to use the lists
19:04:41 <anteaya> a speedy iteration prevents a week of transition
19:04:55 <jeblair> yeah, probably best to do this quickly to avoid confusion
19:05:05 <jeblair> are there outstanding requests from folks we have received on the infra list?
19:05:16 <clarkb> jeblair: there are a few yes
19:05:17 <pleia2> a couple
19:05:29 <anteaya> I'm standing by to offer new patchsets for 116989 if folks have -1s
19:05:44 <jeblair> okay, we should probably avoid asking people to resubmit on the new list, that's just silly
19:05:49 <anteaya> agreed
19:05:58 <jeblair> i think when anteaya's change merges, we should announce the new policy to the old list
19:06:02 <jeblair> ask everyone to subscribe to the announce list
19:06:07 <fungi> agreed
19:06:09 <jeblair> and new requests go to the request list
19:06:09 <anteaya> agreed
19:06:19 <jeblair> and explicitly mention that old requests don't need to be resubmitted
19:06:37 <anteaya> I can bulk import gerrit email addresses to the announce list
19:06:46 <anteaya> anyone think that is a bad idea?
19:07:11 <jeblair> anteaya: we could consider inviting them, but not actually subscribing them
19:07:21 <anteaya> okay, I can invite them
19:07:27 <jeblair> anteaya: mailman lets you do either in bulk
19:07:32 <pleia2> anteaya: that's an option in the interface
19:07:34 <pleia2> yeah
19:07:41 <anteaya> if we prefer I invite, I will invite
19:07:42 <jeblair> (they'll get a message saying 'click here to confirm' etc)
19:07:53 <krtaylor> ++
19:07:54 <jeblair> yeah.  i'd be very much opposed to subscribing without confirmation
19:07:54 <fungi> right, never bulk-subscribe people without prior consent or a very, very good reason
19:07:56 <anteaya> should reduce some cruft right off the bat
19:08:08 <anteaya> invite it shall be
19:08:21 <anteaya> I think that was all I needed here
19:08:27 <anteaya> anything I am missing?
19:08:41 <anteaya> okay thanks
19:09:05 <jeblair> #action anteaya invite third-party email addrs from gerrit to announce list
19:09:32 <jeblair> who wants to send the email to -infra announcing the new lists/policies after 116989 merges?
19:09:51 * jeblair is happy to if no one else loves that idea
19:10:26 <pleia2> I can do it
19:10:26 <fungi> i can as well
19:10:40 * fungi bows to pleia2 ;)
19:10:44 <anteaya> everyone wants that job
19:10:54 <jeblair> #action pleia2 send the email to -infra announcing the new lists/policies after 116989 merges
19:11:03 <jeblair> anteaya, pleia2: thanks!
19:11:05 <pleia2> anteaya: left a comment in the review
19:11:17 <jeblair> #topic  Priority Specs (jeblair)
19:11:19 <clarkb> I left one too which expanded on pleia2's
19:11:27 <jeblair> #link https://review.openstack.org/#/c/100363/
19:11:58 <fungi> i think that one's probably ready for approval unless more people want to go through it?
19:12:10 <clarkb> I was happy with it
19:12:19 * nibalizer here to answer questions
19:12:21 <fungi> or unless nibalizer wants to address any of the suggestions on that last patchset
19:13:01 <nibalizer> ill update it for those suggestions
19:13:14 <nibalizer> clarkb: did you want to talk more about the symlink?
19:13:31 <clarkb> nibalizer: not here, if you update the spec about what that is for I think that is enough
19:13:35 <nibalizer> okay sweet
19:13:36 <nibalizer> will do
19:13:44 <jeblair> nibalizer: also, "Set hiera.yaml appropriately to source both dirs in order" -- does that need more detail too?
19:13:58 <jeblair> that's an infra-root action, right?
19:14:15 <nibalizer> jeblair: no hiera.yaml will be managed by puppet
19:14:24 <nibalizer> it should be a file resource
19:14:31 <jeblair> ok nevermind then.  it can be documented in the puppet
19:14:44 <wenlock> nibalizer, as a side note, we use hieradata strucutre on forj.io, we manage this with puppet, no symlinks required
19:14:54 <jeblair> nibalizer: so we'll wait for your update about the rationale for the symlink, then it looks like it's ready to approve
19:15:06 <nibalizer> okay cool
19:15:38 <jeblair> wenlock: maybe you could weigh in on https://review.openstack.org/#/c/100363 after nibalizer writes the update?
19:15:47 <nibalizer> wenlock: lets follow up after the nmeeting
19:15:49 <wenlock> yes, i'll read up on it today
19:16:09 <jeblair> wenlock: that way we'll know if we're doing something different than you are that requires it, or if we've missed something and don't really need it :)
19:16:21 <wenlock> nibalizer, sounds good, we can point you to our source on that
19:16:31 <jeblair> #link  https://review.openstack.org/#/c/99990/
19:16:58 <jeblair> i think this is probably ready modulo syntax errors?
19:17:08 <nibalizer> i think at this point that one is us fighting with restructured text parsing
19:17:10 <wenlock> jeblair, i'd like to propose that you use librarian-puppet as option in install_module.sh to manage the repos
19:17:19 <clarkb> I need to rereview it with the new problem statement but yes I think it is pretty close
19:17:30 <clarkb> wenlock: I will -2 that :)
19:17:31 <nibalizer> but i think for the ideas there we're largely getting consensus
19:17:35 <clarkb> wenlock: we can talk about why after the meeting
19:17:37 <jesusaurus> i think i cleaned up all the syntax errors, but the work items could use a re-review
19:17:41 <wenlock> jeblair +2 for subtree workflow too, this worked nice on our side
19:17:59 <wenlock> clarkb, yes, i'd like to understand how you will manage tags/revs, etc.
19:18:04 <jeblair> jesusaurus: it's currently failing tests
19:18:15 <anteaya> nibalizer: I agree with the content of 99990 if we can get the rst parsing figured out
19:18:34 <jesusaurus> jeblair: thats an old test, it should get through the check queue in like 6 hours or so
19:18:38 <jeblair> oh ok
19:18:58 <jeblair> #link https://review.openstack.org/#/c/110730/
19:19:03 <jeblair> oh no, i have unaddressed comments
19:19:28 <fungi> jesusaurus: i added some comments to the latest patchset as well (i had them in draft for an earlier one)
19:20:15 <jeblair> anyway, i think resolution to the comments already in that one is straightforward, so please go ahead and review with that in mind
19:20:16 <jesusaurus> fungi: thanks
19:20:36 <fungi> jeblair: i have some more in draft i need to add too, though i can port them forward to the next iteration if i don't get to it before you update
19:21:28 <jeblair> #link https://review.openstack.org/#/c/110793/
19:21:55 <jeblair> a few updates noted inline there
19:22:03 <clarkb> jeblair: I think you need to make at least one edit to 110793 as well
19:22:06 <clarkb> jeblair: but it is pretty close
19:22:24 <jeblair> probably the main thing is that there's a section where i list 3 options for openstack-manuals
19:23:21 <jeblair> option 2 is yucky.  option 3 is probably the default option because it doesn't really change anything from the docs pov
19:23:54 <jeblair> option 1 actually simplifies the jobs somewhat, at the cost of some extra cpu time
19:24:00 <clarkb> I am a fan on 1
19:24:02 <clarkb> s/on/of/
19:24:21 <jeblair> i should probably work with AJaeger on quantifying that and seeing what the impact would be
19:25:13 <jeblair> anything else on these specs?
19:25:37 <fungi> yeah, i think i'm really okay with any of the three options, keeping in mind that eventual optimization with afs will probably trump any of them for efficiency anyway
19:25:57 <jeblair> yup
19:26:07 <fungi> so simpler==better for now probably
19:26:26 <jeblair> #topic  Translations demos active, sent to Daisy (pleia2)
19:26:51 <pleia2> this is mostly an FYI
19:27:04 <pleia2> we have demos up for both zanata on wildfly and pootle 2.6
19:27:32 <jeblair> pleia2: do you have an idea of the relative ease of pupetting those two options?
19:27:43 <clarkb> note the pootle 2.6 demo has not had translate-dev dns udpated to point at it because we lack openid and I want to keep it in a position where its really just a demo and not a dev server
19:27:53 <pleia2> we have step by step instructions for how they both were deployed in etherpads, but neither of them will be easy
19:28:23 <pleia2> zanata is a bit trickier since the wildfly support is not official yet, so it's a bit hacky as they continue to work on it
19:28:32 <clarkb> I think the biggest thing from pootle side is that we will have to run the various django managementy commands some of which expect human input (may need a graphite like hack for that)
19:28:32 <jeblair> pleia2: we do run one django app via puppet (graphite)
19:28:33 <fungi> pleia2: also a gut feel for which would require more ongoing care and feeding (infra core effort)?
19:28:57 <pleia2> fungi: zanata, since we don't work with jboss/wildfly today, and we do work with django
19:29:14 <clarkb> I do have a couple concerns about pootle. The first is allauth makes the openid stuff harder not easier :/ and second the UI is thoroughly unintuitive at least to me
19:29:26 <clarkb> but for the second thing I defer to the translation team(s)
19:29:46 <anteaya> how long do the translation folks need to complete their assessment?
19:29:57 <pleia2> I haven't looked deeply into zanata's openid support, but right now in our demo it is taking the https://launchpad.net/~lyz addresses as logins (we'll need to simplify and restrict this)
19:30:07 <jeblair> clarkb: what do you think needs to happen for openid?
19:30:25 <jeblair> pleia2: in either case, i think nothing short of openid sso is acceptable
19:30:31 <pleia2> anteaya: uncertain, we're getting to the point in the cycle where they will be really busy with translations work
19:30:32 <jeblair> clarkb: for pootle
19:30:40 <anteaya> pleia2: fair
19:30:46 <clarkb> jeblair: allauth needs to support a single openid provider (there is an open bug for this). also allauth and/or pootle need to learn how to do a single type of auth
19:31:08 <clarkb> jeblair: today it looks like you always get local auth in addition to whatever allauth other mechanisms you have enabled
19:31:26 <pleia2> as far as evaluation, Daisy has admin on both systems and I'll be working with her to help present the demos to the team on a schedule she determines
19:31:35 <clarkb> there is an open bug against pootle for the second thing which I need to follow up on and possibly file a bug against allauth for
19:31:38 <anteaya> yay Daisy
19:31:40 <pleia2> if anyone else wants admin, lmk
19:32:00 <anteaya> pleia2: you're a great admin :D
19:32:04 <jeblair> pleia2: do you have any idea how receptive the pootle dev(s) would be to this kind of work?
19:32:32 <pleia2> jeblair: they've really been leaning on django for all openid stuff, clarkb has some open bugs that they've responded  to
19:32:50 <clarkb> jeblair: pleia2: ya I think they would be receptive but have already said go fix it in allauth
19:32:56 <pleia2> yeah
19:34:04 <jeblair> how about zanata?  what's it take for openid there?
19:34:20 <pleia2> it works, haven't looked into restricting to only openid
19:34:37 <jeblair> i should say openid sso
19:34:48 <jeblair> cause it sounds like right now, it asks for your openid, right?
19:35:04 <pleia2> http://15.126.226.230:8080/account/register
19:35:24 <pleia2> yeah, so where it wants openid just put in your http://launchpad.net/~user address
19:35:34 <jeblair> and it also has the "and a local account" problem
19:35:41 <pleia2> yeah
19:36:22 <jeblair> well, i added openid sso to gerrit; i could probably add it to zanata too :)
19:36:25 <pleia2> I don't know what mechanism they're using for this, but they've been eager to help us get support for other things we need
19:36:34 <jeblair> even better if they do it :)
19:36:46 <jeblair> i also added it to pootle, but that's neither here nor there
19:37:51 <pleia2> I think that's it for this week, we'll tackle issues down the road as we come to them and the translations team gets a better idea of what works for them
19:37:56 <jeblair> i think from our pov, openid-sso is critical, and easy of installation/maintenance is the next most important
19:38:02 * pleia2 nods
19:38:24 <clarkb> ++
19:38:26 <pleia2> zanata install steps: https://etherpad.openstack.org/p/zanata-install
19:38:34 <jeblair> #link https://etherpad.openstack.org/p/zanata-install
19:38:55 <pleia2> pootle install steps (down at line 47 and below): https://etherpad.openstack.org/p/pootle-250-upgrade
19:39:21 <jeblair> #link https://etherpad.openstack.org/p/pootle-250-upgrade
19:40:09 <jeblair> we probably have some anti-patters in puppet for gerrit that we can crib for some of the zanata stuff
19:40:13 <pleia2> oh, and zanata will probably be available via ansible..recipes? so hopefully we'd be able to convert them to puppet
19:40:14 <jeblair> anti-patterns
19:40:45 <jeblair> pleia2: cool, thanks
19:40:55 <jeblair> #topic  Open discussion
19:41:08 <anteaya> so something has come out of the reviews so far on my patch
19:41:27 <anteaya> what are the expectations for thrid party folks regarding the two new lists
19:41:30 <fungi> the upcoming renames list has the dashboard puppet module on it, proposed to go to openstack-attic... that can come off the list right?
19:41:41 <anteaya> I want all third party folks to subscribe to both lists
19:41:54 <anteaya> to announce to keep alert for their system if it is disabled
19:42:00 <anteaya> to request to help me out
19:42:18 <jeblair> fungi: yeah, we should just merge a change to readme saying it's dead
19:42:28 <anteaya> https://review.openstack.org/#/c/116989
19:42:53 <fungi> jeblair: i'll propose a bunch of "it's dead jim" patches to projects in the same boat in that case
19:43:09 <jeblair> anteaya: i think that would be useful.  i think announce should be considered a requirement (i don't intend on policing it); requests is a nice-to-have
19:43:12 <anteaya> only if I can call you bones, fungi
19:43:25 <anteaya> jeblair: I can live with that
19:43:39 <krtaylor> ++
19:43:43 <anteaya> I'm not going to police either list
19:43:55 <anteaya> but if they don't know their system is disabled it is on them
19:44:05 <fungi> i think announce should be a very strong suggestion, since if we're making changes you need to be aware of or taking your systems offline, that's where you're going to find out about it
19:44:09 <jeblair> anteaya: exactly
19:44:34 <anteaya> fungi: I tried to capture that strong suggestion in the wording of my patch
19:44:34 <krtaylor> I vote requirement
19:44:40 <anteaya> krtaylor: no
19:44:40 <fungi> and if you aren't subscribed to the announce list or aren't paying attention, then it's your problem not ours
19:44:53 <anteaya> requirements are basis for disabling a system if they aren't met
19:45:01 <krtaylor> anteaya, why not?
19:45:15 <anteaya> if they aren't subscribed to announce disablying their system isn't going to be my action
19:45:39 <jeblair> anteaya: it will also be where we send notifications of policy changes (lack of adherence to which would get systems disabled too)
19:45:48 <anteaya> jeblair: agreed
19:46:11 <krtaylor> I am thinking more in terms of announcements that CI teams will want to know, that is important
19:46:19 <krtaylor> what jeblair said
19:46:22 <anteaya> fungi: also I have tried to capture the strong wording in teh message on the landing page for the list
19:46:32 <anteaya> krtaylor: right
19:47:21 <krtaylor> so why wouldn't it be a requirement? we need a global communication channel
19:47:38 <anteaya> requirements are what gets your system disabled if you don't have them
19:47:49 <krtaylor> or not granted in the first place
19:47:58 <anteaya> I am not going to disable a system if they don't subscribe to a mailing list
19:48:40 <anteaya> they are foolish if they don't, but that is on them
19:48:42 <krtaylor> I don't think that would be a problem, but listing it in the requirements section would be ok
19:48:49 <anteaya> I disagree
19:48:56 <fungi> however they may get disabled because they missed announcements on that mailing list, or they might not find out in a timely manner that they were disabled because we reached out to them via that list
19:49:22 <anteaya> fungi: true
19:49:28 <anteaya> again their responsibility
19:49:43 <anteaya> some of the onus has to be on them for their actions
19:50:24 <krtaylor> true, but not a good track record of that, at least initially
19:50:30 <anteaya> no
19:50:51 <anteaya> so anyway I hope taht clarifies my patch
19:51:19 <krtaylor> I am happy we have the lists, hopefully everyone will sign up
19:51:36 <jeblair> ++
19:53:44 <jeblair> well, if that's it, i reckon we can end early
19:53:56 <clarkb> oh I did the tox and trusty stuff
19:53:58 <clarkb> it went mostly ok
19:54:07 <jeblair> oh cool
19:54:13 <fungi> it went remarkably well, i thought
19:54:21 <clarkb> glance hiccuped and so did a couple of our tools and stackforge puppet
19:54:22 <anteaya> yay tox and trusty
19:54:28 <clarkb> but considering we have several hundred projects it went well :)
19:54:53 <anteaya> :)
19:54:54 <clarkb> thats it
19:54:57 <fungi> and some review teams got a bit of a learning experience about prioritizing prerequisite changes for scheduled infra activities
19:55:06 <jeblair> haha
19:55:36 <clarkb> but we are future proofed until tox does their next release
19:55:50 <anteaya> great
19:55:53 <jeblair> clarkb: is there more to do with trusty?  eg, zuul layout?
19:56:06 <hashar> hey. is that open discussion yet? :D
19:56:16 <clarkb> jeblair: nope, not unless the stackforge puppet team wants to move puppet 2.7 back to precise
19:56:19 <pleia2> hashar: has been for quite some time :)
19:56:23 <hashar> great
19:56:23 <nibalizer> clarkb: yeaaaaa
19:56:27 <nibalizer> so i think that gate is busted
19:56:35 <clarkb> nibalizer: even with mgagne's fix?
19:56:41 <nibalizer> did that land?
19:56:43 <clarkb> yes
19:56:43 <nibalizer> https://review.openstack.org/#/c/116915/ ?
19:56:45 <hashar> so for those that don't know me, I am the continuous guy at wikimedia foundation and I have basically copy pasted Zuul setup to our infra.
19:57:11 <jeblair> hashar: and improved zuul :)
19:57:13 <hashar> I would like to hereby publicly thank you in the name of me and the wikimedia foundation folks for all your hard work supporting third party installation
19:57:16 <nibalizer> clarkb: its like i was saying yesterday, 'double puppet install' isnt the problem, ruby 1.9.3 is the problem
19:57:25 <hashar> from Zuul (which is awesome) to kindly maintaining python-jenkins
19:57:41 <jeblair> hashar: oh, you're very welcome!
19:57:50 <fungi> hashar: you're welcome, and thanks for all your help too!
19:57:51 <mgagne> clarkb: so much lag, no result yet on my test :-/
19:57:53 <jeblair> hashar: thank you for using it and helping us make it better
19:58:11 <zaro> hashar: thanks in turn for your contributions!
19:58:13 <hashar> our jobs are stressful, and little time is spent to say thanks.  So here you have:  merci beaucoup !
19:58:35 <anteaya> thanks hashar
19:58:46 <mgagne> -> Thank you for helping us help you help us all.
19:58:52 <anteaya> :)
19:58:59 <jeblair> and we're going to start using hashar's zuul-cloner soon :)
19:59:00 <hashar> and I got Zuul cloner deployed in production last week. It is now voting as of today ! :D
19:59:04 <jeblair> mgagne: well put! :)
19:59:14 <fungi> hashar: also, in a broader context, thanks for keeping mediawiki and by extension wikipedia working. i use them both a lot
19:59:26 <hashar> (((that is on Wikimedia production, not OpenStack! )))
19:59:28 <anteaya> yes
19:59:30 <ttx> I used that too
19:59:38 <clarkb> hashar: nice!
19:59:40 <jeblair> fungi, hashar: ++
19:59:42 <mgagne> with GLaDOS' voice
19:59:47 <hashar> yeah MediaWiki is quite fun :]
19:59:53 <clarkb> hashar: and thank you!
20:00:08 <hashar> thought it can be scary and is not yet as tested as openstack can be. But we are working on it!
20:00:18 <jeblair> what a nice way to end a meeting :)
20:00:22 <jeblair> #endmeeting