19:02:44 <jeblair> #startmeeting infra
19:02:45 <openstack> Meeting started Tue Aug 12 19:02:44 2014 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:46 <sweston> o/
19:02:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:49 <openstack> The meeting name has been set to 'infra'
19:02:50 <emagana> thanks!
19:02:51 <pleia2> welcome grantbow
19:02:55 <jeblair> #link agenda: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:02:55 <clarkb> o/
19:02:58 <jeblair> #link previous meeting: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-08-05-19.02.html
19:03:14 <jeblair> #topic Puppet module Split out (jesusaurus/nibalizer)
19:03:24 <nibalizer> okay so i guess we decided some stuff last time that i forgot
19:03:37 <nibalizer> but sounds like step 1 is to split out a guniea pig
19:03:42 <nibalizer> so i can do that with storyboard
19:03:54 <jeblair> i probably should use the agree command more
19:04:11 * krotscheck perks up.
19:04:14 <nibalizer> jeblair: you had no chance, i had to do wedding stuff(not mine) last week so my brain was fried
19:04:27 <nibalizer> krotscheck: so yea your patches that haven't landed, we can pivot those to be applied to the new storyboard module
19:04:29 <pleia2> nibalizer: btw, once the guinea pig is done, you're welcome to add me to people who can help with splitting out modules
19:04:37 <krotscheck> nibalizer: Works for me.
19:04:43 <nibalizer> the puppet-storyboard projcet has already been created so thats easy
19:04:44 <jeblair> we didn't land the big storyboard refactor?
19:04:49 <jesusaurus> pleia2: awesome :)
19:04:52 <krotscheck> jeblair: We did.
19:04:56 <krotscheck> jeblair: We’re now building on that.
19:04:58 <nibalizer> i think we should have a little discussion about acls
19:04:59 <jeblair> ah cool
19:05:02 <nibalizer> jeblair: ya krotscheck is a machine
19:05:03 <jedimike> hi
19:05:14 <nibalizer> i.e. does infra-core retain the +2+a on the modules
19:05:24 <sweston> please add me to the list of people who can help with the module split as well.
19:05:24 <nibalizer> or do we give it krotchchek on the storyboard module?
19:05:24 <mordred> yes
19:05:45 <jeblair> krotscheck, nibalizer: does the new refactor work?  ie, is it stable enough for us to pivot to now?
19:05:50 * SergeyLukjanov2 lurking
19:05:56 <krotscheck> jeblair: It’s currently in use.
19:06:05 <krotscheck> jeblair: But there’s one thing left that....
19:06:08 <nibalizer> jeblair: that ^^
19:06:15 <jeblair> once we approve https://review.openstack.org/#/c/99990/ we will make a story for each module
19:06:25 <jeblair> and then all the folks that want to volunteer can assign that story to themselves
19:06:29 <krotscheck> jeblair: Well, there’s one remaining patch that I want to land to make it “stable"
19:06:36 <pleia2> jeblair: great
19:06:51 <jeblair> s/that story/those stories/
19:07:13 <jeblair> nibalizer: can we land that first, then focus on catching the external module up?
19:07:27 <krotscheck> nibalizer jeblair: This one - https://review.openstack.org/113616
19:07:28 <nibalizer> jeblair: lets land krotchekcs patch for stability
19:07:35 <nibalizer> then catch the external module up
19:07:55 <jeblair> #agreed land https://review.openstack.org/113616 to internal storyboard module, then begin moving to external module
19:08:16 <nibalizer> woot
19:08:34 <anteaya> nice use of agreed
19:09:17 <jeblair> anything else on this?
19:09:22 <zaro> o/
19:09:24 * krtaylor notices "agreed", hm I'll have to use that..
19:09:34 <nibalizer> jeblair: acls?
19:09:52 <jedimike> o/
19:09:57 <jeblair> heh, i guess we should expand on mordred's answer to that :)
19:10:05 <mordred> :)
19:10:18 <nibalizer> oh did mordred say something?
19:10:20 <jeblair> nibalizer: infra-core will have +2 on all openstack-infra/ projects (including these)
19:10:30 <nibalizer> oh he said yes
19:10:45 <anteaya> nibalizer: if you need help with the acl in the patch, let me know, I can help you
19:10:53 <nibalizer> anteaya: okay
19:11:06 <nibalizer> aight sweet then i think im good on this topic
19:11:08 <jeblair> nibalizer: once they are split out, we can consider giving folks +2 on individual projects
19:11:27 <nibalizer> jeblair: cool
19:11:46 <jeblair> but probably not right away, so for sanity sake, i'd just put infra-core in the acl files for now
19:11:46 <fungi> we generally accomplish that, as needed, by modifying the acl to use a new core reviewer group and have it include the infra-core group
19:11:52 <jeblair> fungi: ++
19:12:22 <jeblair> #topic Project renames (flaper87,jraim)
19:12:38 <SergeyLukjanov2> I'd like to do this renaming
19:12:51 <jeblair> SergeyLukjanov2: i'd like that too! :)
19:12:53 <Ajaeger> https://review.openstack.org/#/c/113614/ and https://review.openstack.org/#/c/111244/ are also renames
19:12:53 <fungi> flaper87 wasn't going to be around for the meeting sounded like, but said something to the effect of "the sooner the better"
19:12:59 <Ajaeger> Rename Marconi to Zaqar
19:13:06 <fungi> Ajaeger: yep
19:13:13 <Ajaeger> and just pushed: Move openstack-security-notes to attic
19:13:33 <SergeyLukjanov2> ack
19:13:40 <jeblair> Ajaeger: cool, can you add that to https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Upcoming_Project_Renames
19:13:41 <fungi> i tacked on jraim so we could get some clarification on whether the kite rename should also include python-kiteclient
19:13:49 <jeblair> jraim: ping
19:13:51 <Ajaeger> jeblair: will add directly
19:14:00 <jeblair> fungi: i think i was catching us up to the governance repo
19:14:10 <fungi> but wasn't able to get jraim's attention earlier, so he's probably also not around at the moment
19:14:21 <jeblair> fungi: and kiteclient isn't in there
19:14:23 <fungi> jeblair: yep, i figured that out from the wiki history
19:14:36 <jeblair> bug that sort of suggests the question of whether that was an omission from the gov repo
19:14:54 <fungi> mainly wanted to sync up on whether it should be, and whether we should delay the kite rename until it happens
19:15:15 <fungi> so that they get renamed at the same time
19:15:54 <fungi> so anyway, it sounds like maybe just the marconi and security notes renames are ready to go in near term
19:16:02 <SergeyLukjanov2> yup
19:16:14 <jeblair> yeah, let's keep trying to get clarification on that, and defer kite until we do
19:16:34 <clarkb> ++
19:16:40 <fungi> who has dates/times they really want to avoid? should we do friday pst afternoon? earlier?
19:16:47 <SergeyLukjanov2> so, here is the guide for renaming - http://ci.openstack.org/gerrit.html?highlight=rename#renaming-a-project am I right?
19:17:05 <fungi> SergeyLukjanov2: yep. it may or may not be 100% current, but it's close
19:17:15 <jeblair> SergeyLukjanov2: yep; we'll make sure at least one other person is there with you to double check
19:17:18 <SergeyLukjanov2> I'd like to avoid my sunday (your sat/sun night)
19:17:22 <jeblair> we keep finding that little things have changed
19:17:54 <SergeyLukjanov2> I think there were no changes in gerrit since last renaming, so, it should be going good
19:17:55 <clarkb> friday is ard for me but early saturday morning pst should be ok
19:18:02 <fungi> SergeyLukjanov2: generally we try to put together an etherpad with the timeline and cut+paste of the grittier commands so they can be peer reviewed
19:18:21 <fungi> also we want to make sure the pending rename commits are fully reviewed and current (not in need of rebases)
19:18:37 <jeblair> SergeyLukjanov2: what's the latest time friday that would be okay for you?
19:18:41 <SergeyLukjanov2> early sat morning is ok for me
19:18:55 <SergeyLukjanov2> let me calc re friday
19:19:14 <SergeyLukjanov2> so, I'm UTC-4
19:19:22 <jeblair> clarkb: 1600 utc saturday okay?
19:19:29 * clarkb does math
19:19:34 <clarkb> that is 9am? that should work
19:19:42 <SergeyLukjanov2> and 3 am is time when I'm falling asleep
19:19:59 <clarkb> fungi: will you be around?
19:20:01 <SergeyLukjanov2> 1600 utc saturday is ok for me too
19:20:06 <fungi> looks like that's 8pm SergeyLukjanov2's time?
19:20:08 * clarkb is wondering how many schedules we are trying to juggle?
19:20:15 <fungi> clarkb: i'm fine with it
19:20:22 <SergeyLukjanov2> correction: UTC+4 :)
19:20:26 <clarkb> cool why don't we aim for then then?
19:20:48 <jeblair> #agreed project renames 1600 utc aug 16
19:20:51 <SergeyLukjanov2> ok, sounds like we agreed in 1600 utc saturday
19:20:56 <SergeyLukjanov2> :)
19:21:10 <jeblair> did i get that right? :)
19:21:14 <SergeyLukjanov2> I'll prepare etherpad tomorrow and share with you folks
19:21:31 <SergeyLukjanov2> jeblair, I think so ;)
19:21:36 <fungi> SergeyLukjanov2: i can get you links to earlier ones if you need examples
19:21:44 <SergeyLukjanov2> fungi, it'll be great, thanks!
19:21:58 <jeblair> #topic Publish python-jenkins 0.3.3 (last release without pbr) tarball to pypi. (zaro)
19:22:32 <jeblair> zaro: so 0.3.3 fixes the issues with 0.3.1?
19:22:39 <zaro> yes, it does.
19:22:53 <jeblair> #action jeblair Publish python-jenkins 0.3.3 (last release without pbr) tarball to pypi
19:22:55 <zaro> last one without pbr
19:23:11 <fungi> that's a manual upload too, right?
19:23:16 <jeblair> fungi: yup
19:23:38 <jeblair> previous one had a bug, so sort of defeated the purpose :(
19:24:06 <jeblair> (of having a published version before we went and changed _lots_ of stuff)
19:24:24 <zaro> cool, end of topic i guess.
19:24:34 <jeblair> #topic  Administering third party ci gerrit accounts: setting http passwords (anteaya)
19:24:54 <anteaya> hi
19:25:03 <anteaya> so there was an email thread
19:25:14 <jeblair> #link
19:25:14 <jeblair> http://lists.openstack.org/pipermail/openstack-infra/2014-August/001685.html
19:25:16 <anteaya> #link http://lists.openstack.org/pipermail/openstack-infra/2014-August/001685.html
19:25:19 <anteaya> thanks
19:25:27 <jeblair> nope, you got it right :)
19:25:42 <anteaya> and there is the ability for gerrit admins to set an http password for third party cis
19:25:50 <anteaya> vmware would like a password
19:25:53 <jeblair> why?
19:26:21 <anteaya> from the email: We are looking to use some of the Gerrit REST API operations that require authentication
19:26:28 <jeblair> which ones?
19:26:28 <anteaya> that is all I have for the why
19:26:43 <anteaya> ryan was going to try to be here at the meeting
19:26:50 <anteaya> I have forgotten his irc nick
19:26:54 <anteaya> I don't know which ones
19:26:57 <anteaya> :(
19:27:10 <zaro> you don't need admin to create http password.
19:27:19 <anteaya> for third party ci?
19:27:26 <anteaya> which don't have gui access?
19:27:27 <zaro> i believe account holder can do themself
19:27:34 <anteaya> via ssh?
19:27:58 <zaro> ohh, sorry. didn't realize no UI access.  then no they cannot.
19:28:06 <jeblair> i don't think there's a good way for us to set those without actually knowing the passwords.  and i don't want us to become the password reset help desk any more than we already are.
19:28:11 <anteaya> okay yes, so they can't by themselves
19:28:18 <anteaya> kk
19:28:22 <jeblair> so i think there's a pretty high bar for deciding this is a good idea
19:28:31 * anteaya nods
19:28:42 <fungi> especially when they can just use a normal account to make rest api queries
19:28:50 <SergeyLukjanov2> ++
19:28:54 <jeblair> also, third-party ci only needs to do two things authenticated, and ssh access permits both
19:28:56 <clarkb> and the ssh api exposes all the things too
19:29:01 <clarkb> jeblair: ++
19:29:35 <anteaya> okay so I will share the meeting logs in response to the email and if he needs more air time hopefully he will attend in future
19:29:37 <anteaya> thanks
19:29:39 <anteaya> I'm done
19:29:47 <jeblair> anteaya: thank you!
19:29:54 <jeblair> #topic  Bug Day proposal: August 19th, alt suggestions: August 26th, September 9th (pleia2)
19:30:10 <pleia2> so I noticed our bug numbers creeping up and tossed some dates out
19:30:22 <Ajaeger> FYI, September 9th the Documentation team will do a Bug day - but that's not a conflict IMHO
19:30:25 <pleia2> (skipped labor day week)
19:30:25 <clarkb> next week is hard for me particularly with the trusty and tox switches coming up
19:30:49 <clarkb> I would +1 the 26th
19:30:59 <fungi> 26th sounds great to me
19:31:03 <anteaya> I'm better on the 26th
19:31:05 <jeblair> ++26
19:31:07 <pleia2> great
19:31:09 <SergeyLukjanov2> ++26
19:31:16 <pleia2> should we incorporate storyboard projects into this bug day?
19:31:27 <jeblair> mordred: do you think we'll be able to import by then?
19:31:32 <pleia2> I don't actually know anything about storyboard's API for writing a script (it has one, right? :))
19:31:32 <mordred> yes
19:31:39 <mordred> jeblair: I'm finishing off teh import script right now
19:31:45 <fungi> do we normally incorporate anything besides the openstack-ci project bugs?
19:31:47 <mordred> https://review.openstack.org/113624 fwiw
19:32:03 <pleia2> fungi: well, storyboard has some of our projects that were origially openstack-ci on launchpad
19:32:22 <fungi> pleia2: oh, yeah makes sense then
19:32:24 <clarkb> it might be a good way to kick the tires on storyboard too
19:32:34 <pleia2> clarkb: that's what I'm thinking
19:32:45 <pleia2> I haven't actually done anything with storyboard aside from reading it :)
19:32:49 <fungi> storyboard tire-kicking day ;)
19:33:07 <nibalizer> pleia2: i created a test story
19:33:10 <mordred> well, krotscheck and I will both be not here
19:33:12 <nibalizer> then found out you cant delete them :/
19:33:20 <pleia2> nibalizer: haha, oops
19:33:30 <rcarrill`> nice
19:33:31 <anteaya> oh yeah krotscheck will be honeymooning
19:33:34 <krtaylor> thats good to know
19:33:48 <pleia2> ok, so maybe bump storyboard tire kicking until next time
19:33:50 <krotscheck> which is slightly different from mooninhoneys
19:33:57 <anteaya> :D
19:33:59 <rcarrill`> lulz
19:34:06 <pleia2> krotscheck: also, congrats :)
19:34:09 <jeblair> i think we can kick storyboard's tires
19:34:11 <rcarrill`> yeah, congrats
19:34:22 <krotscheck> Well, y’all can hit as many bugs as you want to, and file them as stories, just don’t expect much movement on them.
19:34:25 <fungi> i'm fine with it, as long as the tires don't kick back
19:34:29 <pleia2> alright
19:34:35 <jeblair> i'm not interested in using launchpad anymore for infra bugs; it's time to start really using storyboard
19:34:38 <pleia2> all the bugs for when krotscheck returns \o/
19:34:44 <mordred> jeblair: script almost done!
19:34:52 <mordred> krotscheck: btw - I found a bug in StoryTags
19:35:15 <pleia2> so is there a way to query storyboard from a script?
19:35:24 <clarkb> jeblair: ++ we haev to switch at some point and every time I have used storyboard I have been happy
19:35:31 <rcarrill`> curl?
19:35:59 <jeblair> #agreed bug day august 26 (and bugs will be imported into storyboard by then)
19:36:03 <ttx> pleia2: curl would work, although i would love if someone would work on python bindings
19:36:14 <mordred> pleia2: python-storyboardclient is a TDL item
19:36:19 <pleia2> ok
19:36:26 <pleia2> well, I'll come up with something
19:36:41 <ttx> can't be worse than launchpadlib anyway :)
19:36:45 <rcarrill`> haha
19:36:47 <rcarrill`> indeed
19:37:01 <jeblair> pleia2: thanks!
19:37:04 <krotscheck> Oh man, I’m glad I created a sorting patch :)
19:37:07 <mordred> ZOMG launchpadlib
19:37:07 <jeblair> #topic Refactor of artifact upload scripts (rcarrillocruz)
19:37:11 <rcarrill`> that's me
19:37:16 <ttx> well, to be fair launchpadlib is decent. It's launchpad APi that is horrible :P
19:37:16 <rcarrill`> #link https://review.openstack.org/#/c/109816/
19:37:29 <rcarrill`> i've been chatting with fungi and clarkb about this
19:37:41 <rcarrill`> and also chatted with jeblair at mid-cycle sprint
19:37:55 <rcarrill`> i'd like to get consensus on the change
19:38:02 <rcarrill`> should it be a refactor for just java things?
19:38:22 <rcarrill`> or are we open to have a generic framework/script to uplod all sorts of artifacts?
19:38:25 <rcarrill`> pypi
19:38:26 <rcarrill`> wheels
19:38:29 <rcarrill`> jenkins
19:38:31 <rcarrill`> maven
19:38:32 <rcarrill`> ...
19:38:43 <jeblair> rcarrill`: as i recall, it was mostly the java stuff that you needed to consolidate for your use-case, right?  so either will work for you?
19:39:04 <jeblair> consolidate and genericize
19:39:12 <rcarrill`> yes, but clarkb says he's not very keen on having a monolithic script for all kind of artifacts
19:39:22 <rcarrill`> i.e. not -t ARTIFACT_TYPE
19:39:22 <clarkb> my opposition to doing everything in a giant complicated script is that we have been very unixy so far and makinga one size fits all script is not how anything else works there
19:39:41 <fungi> rcarrill`: i think most of those other artifact types use widely varying tools/commands to prepare and upload, and the script wouldn't really do much in common ultimately
19:39:53 <jesusaurus> i agree with clarkb that we should have the One Way to do maven, then a different One Way to do pypi
19:40:03 <jeblair> clarkb: but there's some commonality in the download part yeah?
19:40:15 <fungi> for most of them, the bulk of the duplication we'd avoid would be in the license boilerplate comment block
19:40:18 <jeblair> clarkb: i'm guessing you'll say "have a download script, and N upload scripts" :)
19:40:19 <rcarrill`> yes
19:40:20 <clarkb> jeblair: yes, the download part has some commonality. the difference are in the upload to $repo
19:40:26 <clarkb> jeblair: that would be fine
19:40:34 <rcarrill`> to be fair, i think we could have a common artifact upload thingy , but bash is not the way to go
19:40:41 <Ajaeger> Is there a way to create a library that can be included for some common functions?
19:40:45 <rcarrill`> so, imho we could just have my change for java stuff
19:40:56 <rcarrill`> and then we can work on something on later that is more flexible than bash
19:41:15 <fungi> yeah, it seems like maven nexus and jenkins-ci are probably similar enough that they benefit
19:41:44 <clarkb> fungi: they are the same thing. the only differences are nexus location and filenames
19:41:45 <rcarrill`> agreed on having the change on just nexus, and upload either java package OR jenkins package? that way no point of differentiating if the stuff is jenkins of java
19:42:00 <rcarrill`> clarkb: ^, yup, i agree with you
19:42:20 <jeblair> Ajaeger: yes, that would be possible
19:42:24 <rcarrill`> after our chat last week, i give you that
19:42:29 <jeblair> (so the download part could be 'sourced')
19:42:37 <fungi> rcarrill`: yeah, could probably branch on the filename extension and not need explicit artifact type parameters even
19:42:42 <zaro> not exactly the same, jenkins-ci is artifactory while maven central is nexus.
19:43:01 <rcarrill`> but curl one-liner would work the same, not zaro?
19:43:13 <zaro> for download only i think
19:43:46 <zaro> for maven central (nexus) they employ a two step upload process.
19:43:50 <rcarrill`> zaro: could I work with you on that?
19:43:55 <zaro> yes.
19:43:57 <rcarrill`> it's a PITA to open an account myself for testing
19:44:05 <rcarrill`> we could just use openstack-infra account for that
19:44:21 <zaro> you'll need the password.
19:44:36 <rcarrill`> iirc, oss sonatype site requires an approval process to get an account
19:44:42 <rcarrill`> it's not something immediate to get
19:44:48 <fungi> rcarrill`: right, you have to open a jira ticket
19:44:59 <zaro> just do it!
19:45:04 <fungi> and then wait for them to process it
19:45:09 <rcarrill`> anyways, overall the change looks good?
19:45:21 <rcarrill`> pulling the -t switches
19:45:29 <fungi> (not entirely unlike our third-party ci service account request workflow)
19:45:33 <rcarrill`> and just copying .hpi / .jar artifacts
19:45:42 <rcarrill`> ?
19:45:46 <zaro> now that i think about it. i don't think it will work for maven central.
19:46:25 <zaro> you need to upload then do another request to "approve" to actually publish it.
19:46:43 <zaro> anyways. i'll review again.
19:46:49 <clarkb> rcarrill`: ya overall it is fine. I think we should just rip out the branch logic
19:46:52 <rcarrill`> cool
19:47:03 <jeblair> #topic  Process to deprecate drivers/plugins and their corresponding CIs (emagana)
19:47:07 <zaro> ohh, i agree with clark there as well.
19:47:15 <emagana> hi
19:47:24 <rcarrill`> we have a deal then
19:47:49 <emagana> Just wondering if there is a process in place to deal with the plugins/drivers that are being deprecated
19:48:00 <rcarrill`> zaro: will make another patchset and ping you then
19:48:08 <emagana> as well as the process to deprecate them if they do not have a CI
19:48:09 <jeblair> emagana: what plugins/drivers are being deprecated?
19:48:23 <emagana> in Neutron: OVS, LB, NXOS
19:48:27 <fungi> emagana: that's more a decision on the part of the projects in which those drivers exist or integrate
19:48:29 <emagana> jeblair: maybe more
19:48:31 <fungi> so in that case, neutron
19:48:57 <emagana> fungi: understood!
19:49:15 <fungi> if there are third-party ci systems which correspond with them and are being taken offline as well, we appreciate a heads up so we can disable their service accounts
19:49:28 <jeblair> yep, and the wiki pages for them should be updated too
19:49:36 <emagana> fungi: That is the kind of guidence I am looking for
19:49:51 <emagana> I am planning to run an audit for the plugins/drivers CI
19:50:02 <emagana> I know, I will not have many friends
19:50:31 <emagana> The idea is to be sure that all drivers/plugins are being tested properly
19:50:36 <clarkb> emagana: ++
19:51:23 <jeblair> emagana: that would be awesome; thanks
19:51:25 <krtaylor> emagana, what is the output of the audit?
19:51:35 <emagana> I will update NeutronPolicies for Plugin and Drivers with the results: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
19:51:53 <krtaylor> emagana, understood
19:52:01 <emagana> krtaylor: ensure quality! and deprecated anything that is not being properly tested
19:52:12 <krtaylor> emagana, feel free to bring this up in the next third-party meeting as well, we can spread the news
19:52:19 <emagana> Thanks!
19:52:29 <emagana> ok, will provide results next week
19:52:39 <jeblair> #topic  Open discussion
19:52:39 <emagana> that is all I wanted to share about this
19:52:57 <jedimike> o/
19:53:00 <jeblair> anteaya: what's the status of account renames?
19:53:01 <emagana> jeblair: I have a question about Multi-node testing
19:53:24 <anteaya> right now I am hoping either you or someone else can help me append CI to the end of them all
19:53:30 <jedimike> I have a small nodepool feature I'd like to run by you all
19:53:30 <anteaya> then we can merge teh js patch
19:53:43 <jeblair> anteaya: can you prepare an etherpad with a list of the names?
19:53:45 <anteaya> after I get gerrit permissions then go through them and chance the name
19:53:56 <anteaya> jeblair: oh goodness I have been working on it for 3 months
19:54:13 <jeblair> anteaya: yeah, that's too long.  i'm ready to just name them myself.
19:54:16 <clarkb> anteaya: I think we need a clear old name to new name map
19:54:22 <anteaya> #link https://etherpad.openstack.org/p/automated-gerrit-account-naming-format
19:54:29 <anteaya> jeblair: go for it
19:54:30 <clarkb> then whoever can do it.
19:54:45 <anteaya> if you want it I will support you and clean up afterward
19:55:36 <jedimike> We've been having some problems with nodepool and the ready-script recently. Our ready-scripts do some nice things like update git repos, set hostnames, but because we generate our images every night, they're not absolutely essential.
19:55:36 <jeblair> i will tend to give them _very bad names_
19:55:42 <jedimike> So we'd like to have an option that lets us tolerate errors in the ready-script, so if it fails to run, the node is still used.
19:55:52 <jeblair> like "Unknown Function Third Party CI"
19:55:53 <anteaya> jeblair: there are no names they will like
19:56:13 <clarkb> jedimike: the whole point of a ready script imo is to make sure the node is ready. if it fails the node is not ready.
19:56:20 <clarkb> jedimike: tolerating failures should happen in the script
19:56:34 <emagana> jeblair: During the Neutron mid-cycle sprint in Minnesota, we discussed the need for having a Multi-node testing environment, specially for DVR (Distributed Virtual Router). So, I created a spec in Infra: https://review.openstack.org/#/c/106495/
19:56:43 <anteaya> jeblair: do it, they will yell at me and I will take it
19:56:59 <anteaya> and I don't have to keep thinking about how to make everyone happy, because I can't
19:56:59 <jeblair> jedimike: yeah, i think updating git repos is probably not something that should be in a ready script
19:57:04 <jedimike> clarkb, yes, but sometimes nodepool just isn't running the script, and because it doesn't log anything useful when it fails to run the ready script, we've had days where no jobs are running and we don't know why, and our scripts run fine as far as we can see
19:57:07 <emagana> jeblair: I just wanted to know if you have this cover by a different spec.. anteaya recommended to bring this question here
19:57:15 <jedimike> I have a patch currently in review to fix that though, https://review.openstack.org/#/c/113287/
19:57:24 <jeblair> jedimike: well, "just not running the script" is a pretty clear bug :)
19:57:27 <fungi> jedimike: we do it in our prep scripts instead, and then pull whatever has changed that day at the start of jobs
19:57:47 <fungi> rather than when the node goes ready
19:57:49 <jeblair> jedimike:  part of the reasoning for that is that nodes can sit in ready state for a long time
19:57:57 <jedimike> i see
19:57:58 <clarkb> emagana: there isn't another spec. afazekas is just doing the work
19:58:05 <jeblair> so if you want something to be current, doing it at the start of the job is the best place
19:58:21 <clarkb> emagana: it is something that was made possible months ago by a new nodepool featuer and no one did anything with it until afazekas stepped up
19:58:35 <jeblair> jedimike: ++ on better logging
19:58:56 <emagana> clarkb: should we abandon the spec that I created and just let the work continue?
19:59:13 <jedimike> jeblair, yeah, it's caused headaches that the scripts look fine, run fine when we run them, but nodepool just threw away stdout and stderr so we can't see what happened
19:59:36 <emagana> clarkb: I think afazekas could point his work to this spec
19:59:41 <clarkb> emagana: I don't necessarily thing it needs abandoning as it does spell out the neutron use case. But I don't think the spec was required to start the work
19:59:45 <clarkb> emagana: yup
19:59:49 <jedimike> so, I'll make a note to look at our ready scripts and see if they can be more minimal too, thanks
20:00:09 <anteaya> time
20:00:30 <jeblair> thanks all!
20:00:32 <jeblair> #endmeeting