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