19:03:01 #startmeeting infra 19:03:02 Meeting started Tue Jul 25 19:03:01 2017 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:05 The meeting name has been set to 'infra' 19:03:07 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:13 #topic Announcements 19:03:22 #info Seeking volunteers to help write and/or present a 20-minute Infra team update at the Sydney, AU summit this November 19:03:26 i gave the foundation coordinator for the project updates a heads up to count infra in this time 19:03:36 #info Don't forget to register for the PTG if you're planning to attend 19:03:45 #link https://www.openstack.org/ptg/ PTG September 11-15 in Denver, CO, USA 19:03:53 I started making some notes locally, I can push them up to an etherpad 19:03:53 #link https://etherpad.openstack.org/p/infra-ptg-queens Infra planning pad for Queens PTG in Denver 19:03:54 * jeblair sneaks in 19:04:01 * mordred says hi 19:04:02 thanks pabelanger! 19:04:06 as always, feel free to hit me up with announcements you want included in future meetings 19:04:19 #topic Actions from last meeting 19:04:32 #link http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-07-18-19.03.html Minutes from last meeting 19:04:40 ianw abandon pholio spec 19:04:44 i approved that earlier today 19:04:48 lemme get a link 19:04:52 cool 19:05:27 #link https://review.openstack.org/486794 Abandon pholio spec 19:05:35 * fungi apologized for only being semi-prepared 19:05:42 er, apologizes 19:05:56 #action fungi get switchport counts for infra-cloud 19:06:08 i'm still blocked on getting the details back from hpe 19:06:26 fungi start an ML thread on cleaning up logging for dead or mostly-dead channels 19:06:51 #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/119906.html Cleaning up inactive meetbot channels 19:07:01 that's progressing nicely 19:07:12 fungi, will you propose a change for the changes that nobody does directly? 19:07:36 AJaeger: yes, probably in another week-ish 19:07:46 giving people a chance to find out and object 19:08:09 still looking for people to pop into some of those channels and give them a heads up about the discussion too, as my message to the ml indicated 19:08:34 we've got a couple channel removals proposed (i merged one late friday) and a couple channel additions waiting to take their place in the system-config repo 19:08:38 understood, thanks 19:09:10 fungi start a ML thread on continuing to operate http://apps.openstack.org/ 19:09:42 #link http://lists.openstack.org/pipermail/openstack-operators/2017-July/013965.html Taking down the App Catalog (apps.openstack.org) 19:10:24 after digging back into the governance change the tc approved, it actually stated we would stop publishing that site, so i think we have grounds to take it offline immediately but i figured i'd give to the end of the month 19:10:34 also that reminded me it's been marked "beta" this entire time 19:10:50 so hopefully nobody's surprised if it goes away without a placeholder explaining what happened to it 19:11:21 but regardless, between the commit message in the governance change and my announcement to the ops ml, the cause should be reasonably discoverable 19:11:30 more like "google" beta than "apple" beta 19:11:37 hah 19:11:42 more like "beta" radiation 19:12:10 #topic Specs approval 19:12:41 we don't seem to have anything new up this week, though AJaeger has a general topic coming up which is currently a wip spec (but we can discuss that in a few minutes) 19:13:25 also, as mentioned in the action items portion of our meeting, i did merge ianw's specs change (linked there) to officially abandon the pholio spec 19:13:39 #topic Priority Efforts 19:14:00 did anybody have any important notes or blockers to bring up for any of our priority efforts? 19:14:12 didn't see any on the agenda 19:14:16 the gerrit-upgrade topic has a couple changes to deal with some gerrit database things we discovered 19:14:31 #topic Priority Efforts - Gerrit 2.13 Upgrade (clarkb) 19:14:31 the one against puppet-gerrit will likely need supervision and a review.openstack.org gerrit service restart 19:14:48 just so that we don't get caught later with any potential problems wondering what changed 19:14:59 (it is expected to be a noop though) 19:15:45 #link https://review.openstack.org/487156 Explicitly enable utf8 on jdbc connection url 19:15:48 that one? 19:16:04 yup 19:16:34 cool. on a related note, we talked about potentially upgrading our trove instances so that we can support full-length utf-8 codepoints 19:16:51 as a separate maintenance likely, though i suppose we could do that before the 2.13 upgrade if we wanted 19:17:04 should be relatively brief 19:17:16 if anybody's eager to dig into that 19:17:26 I've also started the ground work for running zuul on review-dev.o.o to test against gerrit 2.13. For zuulv3 I expect that I need python3 at this point? does it need to be 3.5 for feature reasons? also is bubblewrap required if just running noop jobs? 19:18:00 you can use nullwrapper driver to skip bubblewrap 19:18:20 pabelanger: does it even get that far if using noop though? I guess thats the question 19:18:32 is "noop" still magical like it was in 2.5? 19:18:41 clarkb: Ya, it should be 19:19:37 review-dev has python3.4 not 3.5 so if I need 3.5 I'll need to run this elsewhere. Was hoping to run it on a proper infra instance just so that others could poke at it but can also run locally easily enough 19:20:03 we still have zuulv3-dev running too, maybe you can just use that 19:20:03 clarkb: I don't know that we know if 3.5 is needed v 3.4 19:20:17 Hmm, that is trusty I think 19:20:18 i would be surprised if it didn't work with 3.4, but yeah i also don't know if anyone's tried that 19:20:28 clarkb: 3.4 is not tested though ... so yeah 19:20:57 anything else to cover on this topic? 19:21:06 nope I think next week I should have a lot more info 19:21:30 thanks clarkb! 19:21:37 #topic Zuul v3: Consistent Job Names (AJaeger) 19:21:57 oh crap - I mean to read thatmore 19:22:07 mordred: clarkb: the only thing i know zuulv3 needs py 3.5 for is zuul-web for the async code 19:22:14 #link https://review.openstack.org/386717 "Zuul v3: Consistent Job Names" spec 19:22:33 I've put up a job naming proposal for Zuulv3 jobs, see https://review.openstack.org/#/c/386717/ . It will be a guideance for teams on how to name the jobs. 19:22:35 My questions for discussion are: 19:22:39 1) Is it worth persuing this further? Do we want something like this? 19:22:41 2) Where should this document life? infra-specs, infra-manual, or anywhere else? 19:22:43 3) What are next steps? 19:22:45 I don't want to discuss the items in the document, let's do that in gerrit - or after addressing the three questions above, please. 19:22:53 Shrews, mordred, clarkb: (yeah, i think 3.4 is worth a try for this purpose) 19:23:03 jeblair: Shrews noted thanks 19:23:20 2: infra-manual maybe? 19:23:29 AJaeger: if we want to do it, we should land it soon. I'd like to start bringing new zuulv3 online this week for shade 19:23:40 yeah, so probably easiest first to tackle the question of whether recommendations on how jobs should be named is suitable as a spec, or should be a living document like an infra-manuals (sub)section 19:23:43 * AJaeger can do it quickly. 19:23:54 If we agree on direction, we can merge - and iterate later... 19:24:15 1: probably -- i don't know that i care about too much in detail, but it's worth noting that job names are a common and can be defined in any of 1800 git repos, so at least *some* guidance for a project of openstack's size is necessary i think 19:24:17 separate infra-manual page would be my other idea 19:24:21 the doc seems pretty solid to me - there'sa question in there that jeblair might want to respond to 19:24:46 i'll take a look 19:24:52 yes, pabelanger added something today during his review 19:25:07 jeblair, AJaeger: yah- we should maybe add a note about folks adding jobs in their own repo potentially prefixing them with something to avoid name clashes or something 19:25:33 +1 to name clashes 19:25:37 Where prefix == repo name? 19:25:38 like - creating a job called "test-mysql" in the nova repo is probably bad 19:25:47 yup. 19:25:50 so my take on it is... if it's a one-time plan to rename jobs then that makes sense in a sepc. if it's a reference document with recommendations for reviewers or authors of jobs then that's more suitable for the infra manual 19:25:52 persia: yah - "nova-test-mysql" would likely be a better choice for sucha job 19:26:01 yup 19:26:13 fungi: I think it's a eference document with recommendations for reviewers or authors of jobs 19:26:29 openstack should be reserved for -infra too 19:26:44 fungi, AJaeger: then for question 3 -- maybe we should wind down the conversation in the spec, and then move it to -manual without merging the spec? 19:26:58 like, let's address any outstanding questions there, then move 19:27:08 specs are more of a vehicle for tracking some specific work with a defined start and end condition. at some point the spec reaches implementation or abandonment 19:27:32 jeblair: that approach works for me. 19:27:40 so yes, i'm in favor of a change of venue to the infra-manual repo 19:28:04 as a living document of job naming recommendations 19:28:14 and/or reviewing criteria 19:28:18 agreed, fungi 19:28:47 #agreed Let's put recommendations for creating and reviewing jobs (including their names) in the Infra Manual 19:29:16 optionally, review criteria could belong in the config repo readme 19:29:19 So, next steps: I'll update based on comments here, leave it for two days for review, adress comments and move to infra-manual ? 19:29:42 AJaeger: that sounds like a great plan--thanks! 19:30:25 * AJaeger will ping everybody after update - and we can iterate further after merge for anything we miss 19:30:30 i think the manuals review process is likely better suited and has less overhead than the specs review and approval process (which is bottlenecked on me, in particular( 19:31:12 ok, I'm fine closing the topic and handing over to eumel8 19:31:27 #topic Installation of translation check site with Openstack-Ansible (eumel8) 19:31:43 yeah, thx. We're just finished with developement of the new translation check site based on openstack ansible. 19:31:47 #link http://git.openstack.org/cgit/openstack-infra/infra-specs/tree/specs/translation_check_site.rst "Provide a translation check site for translators" spec 19:32:02 now it's time to bring up the new server with this stuff 19:32:03 #link http://lists.openstack.org/pipermail/openstack-infra/2017-July/005494.html "Translations-test site" ML thread 19:32:28 my question would be how to proceed 19:33:36 does this get deployed on a single server and then update itself periodically? 19:33:46 and what do the deployment steps look like? 19:34:11 I have an old proposal based on puppet translate module: #link https://review.openstack.org/#/c/276466/ 19:34:15 i expect we need a puppet module or at least a new class in the openstack_project module which acts as a wrapper around the deployment commands so that we can redeploy it with our server launch scripts 19:34:31 I would write a new one for osa 19:34:44 #link https://review.openstack.org/276466 Manifest for configuration translation checksite 19:35:06 yes, thats right, fungi 19:35:15 okay, so looks like we already have a module: 19:35:41 #link https://git.openstack.org/cgit/openstack-infra/puppet-translation_checksite 19:36:35 so i suppose you could mostly gut the manifests/init.pp for that and turn it into a wrapper for whatever the setup is for your cronjobs and getting ansible installed and whatnot? 19:37:03 ooohh, right, this was the prior devstack approach, i remember now 19:37:10 installation steps are here: #link https://github.com/eumel8/translation_checksite/blob/aio/install.sh#L8-L45 19:37:31 maybe there is no module necessary 19:38:21 you can likely get away with just a simple server set up via puppet in system-config then run osa out of puppetmaster cron like we run our other ansible stuff 19:39:03 basically just use puppet for getting our base server stuff in place for sysadmin access, exim setup, package updates 19:39:13 agree, looks like basic server gets mostly everything 19:39:25 then just running openstack-ansible gate script 19:39:43 clarkb: sounds good, you have an example? 19:39:55 eumel8: I am not sure if we have any examples of that 19:40:04 ok 19:40:24 we run cloud-launcher and infracloud out of cront today 19:40:27 looks like the zanata_sync cronjob wants to refresh horizon twice an huor? 19:40:31 er, twice an hour 19:40:46 yes, fungi 19:40:58 which is ~ the cadence for our ansible update cycles anyway 19:42:46 and i guess the creates parameter to the install_aio exec is meant to make sure it only runs once after the server is created? 19:43:12 should we worry about OSA getting installed into our control plane? It is possible they could access something private? 19:43:20 hieradata for example 19:44:02 pabelanger: ya there is an implicit trust of the ansible that is executing on the puppetmaster 19:44:12 do we need to actually invoke it on puppetmaster, or just have puppetmaster run a simple playbook which installs osad aio on the remote server? 19:44:26 ansible calling ansible, basically 19:44:41 fungi: that sould work, its basically how we restrict puppet access to only what it needs 19:44:44 fungi: I think that - and then we could have osad run in a cron on the remote server itself even 19:45:38 or have the puppetmaster calling a playbook in its normal 15-45 minute cycle which does the horizon refresh 19:45:59 again by having puppetmaster's ansible call the remote ansible 19:45:59 that seems fair 19:46:11 ++ 19:46:31 sorry, why would that refresh not be driven by a cron job local to that host? 19:46:42 do we have any volunteers familiar enough with our puppetmaster-side playbooks to help eumel8 with the changes necessary to add this? 19:46:51 ianw: it could be either 19:47:25 i don't really know which would be better in that case 19:48:07 Is this something before or after PTG? 19:48:12 but we at least need something creating the cronjob and installing things after the server is created and hopefully idempotently updating it from something declarative in system-config 19:48:53 eumel8: what's the timeframe the i18n team is looking for there? is it something they're anticipating having available for pike string freeze or during queens cycle? 19:49:33 pabelanger: we need this before string freeze but I don't know the exact date. 19:49:55 eumel8: https://releases.openstack.org/pike/schedule.html 19:50:13 Aug 11 hard string freeze 19:50:14 #link https://releases.openstack.org/pike/schedule.html Pike Release Schedule 19:50:35 so a little under two weeks from now 19:51:05 I see, AJaeger, thx 19:51:33 I can help review code, but not sure I have bandwidth before PTG 19:51:42 #link http://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks infra playbooks 19:52:02 #link http://git.openstack.org/cgit/openstack-infra/system-config/tree/run_all.sh script which periodically runs infra playbooks 19:52:29 those are the starting point for where people were talking about doing this, as opposed to having to do much any of it in puppet 19:53:00 ok 19:53:28 eumel8: ping me if you get stuck 19:53:40 seems like we're all spread pretty thin, but if you ask questions in #openstack-infra hopefully people can help you along 19:54:02 ++ 19:54:10 i have a couple other quick housekeeping topics to get through in the next 6 minutes before our time's up 19:54:11 thx pabelanger, it's a hard time frame, I know. 19:54:24 thanks for bringing this up in the meeting, eumel8! 19:54:39 thx to all for the time 19:54:47 it's why we're here every week 19:54:55 :) 19:54:59 #topic August 15 meeting (fungi) 19:55:05 i'll be quick on this one 19:55:26 i need a volunteer to cover chairing the august 15 meeting 19:55:38 i think 19:55:51 that is a tuesday at least :) I will be around 19:56:14 yeah, looking at the schedule, i still do 19:56:30 need to take christine to an appointment on the mainland and likely won't be back home until after the meeting 19:56:40 thanks clarkb! that'll be a huge help 19:56:40 a wednesday for some :) i am also around 19:56:52 you and ianw can arm wrestle for it 19:56:57 or have a dance-off 19:57:00 your call 19:57:09 consider me backup 19:57:17 backup dancer? 19:57:30 this meeting will be awesome 19:57:34 #topic PTL election season (fungi) 19:57:36 left shark 19:57:48 i'm going to become a backup dancer 19:57:53 ianw: I am happy that left shark is known in australia 19:58:25 we're coming up on the nomination period for ptls for the queens cycle 19:58:35 and just in case anyone was wondering, i'm not planning to run again 19:58:51 it was awesome being ptl but after four cycles it's time to let someone else take a turn 19:59:17 thanks fungi for your leadership as PTL! 19:59:30 ++ Thanks indeed 19:59:40 we've got excellent people on the team who are more than capable of taking the reins, and i'll be here to help out with any of it you need 20:00:09 fungi: yes thanks! 20:00:13 so any of you considering running, be thinking about your platform statements. candidacies open for nomination in ~6 days 20:00:16 fungi: does that include dancing? 20:00:24 i hope it includes dancing 20:00:37 anyway, we're over time. thanks everyone! 20:00:52 i'll also be announcing my non-cacdidacy on the ml(s) shortly 20:01:08 er, non-candidacy (i can't type today) 20:01:10 #endmeeting