19:02:41 #startmeeting infra 19:02:41 Meeting started Tue Jul 5 19:02:41 2016 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:45 The meeting name has been set to 'infra' 19:02:47 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:02:53 #topic Announcements 19:02:58 #info Reminder: late-cycle joint Infra/QA get together to be held September 19-21 (CW38) in at SAP offices in Walldorf, DE 19:03:04 #link https://wiki.openstack.org/wiki/Sprints/QAInfraNewtonSprint 19:03:10 also, for those of you who missed last week's meeting due to travel/holiday/other, we have two new infra-core reviewers/infra-root sysadmins: rcarrillocruz (just back from holiday) and ianw (now on holiday himself, i believe) 19:03:17 \o/ 19:03:25 \o/ 19:03:26 \o/ 19:03:31 congrats! 19:03:37 thx folks :-) 19:03:48 #topic Actions from last meeting 19:03:50 #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-28-19.03.html 19:03:56 clarkb bring xenial default job transition discussion to the mailing list 19:03:58 #link http://lists.openstack.org/pipermail/openstack-infra/2016-June/004479.html 19:04:00 discussion underway! 19:04:02 o/ 19:04:16 that's all we had from last week's actions 19:04:26 thank you for that -- i was much more able to participate in ml discussion on that last week than i would have otherwise 19:04:35 and there's a discussion topic proposed later in the meeting to go into detail 19:04:47 #topic Specs approval 19:04:52 #info APPROVED Update Artifact Signing details 19:04:56 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/artifact-signing.html 19:05:02 #topic APPROVED Add wiki modernization spec 19:05:06 \o/ 19:05:07 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/wiki_modernization.rst 19:05:11 \o/ 19:05:26 ^^ which will be real the next time the specs jobs runs ;) 19:05:38 i just ran it moments ago, so should be there now? 19:05:44 404 here 19:05:52 404s here too 19:05:58 (had to look up the trigger-job.py syntax since it was only in my history on the old zuul) 19:06:00 o/ 19:06:06 I have http://specs.openstack.org/openstack-infra/infra-specs/specs/wiki_modernization.html 19:06:06 \o 19:06:10 oh 19:06:13 #undo 19:06:14 Removing item from minutes: 19:06:15 the .rst file 404s 19:06:17 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/wiki_modernization.html 19:06:21 thanks 19:06:23 aha thanks anteaya 19:06:29 welcome 19:06:38 i formed the link incorrectly since i wrote the notes before that job ran ;) 19:06:44 ah 19:06:44 #topic Specs approval: EXTENDED Finglonger (nibalizer) 19:06:47 #link https://review.openstack.org/310948 19:06:52 looks like this needed a little more time to bake in review 19:07:15 nibalizer: do you want to shoot for council voting on it this week, or does it need more work still? 19:07:48 i'm guessing we have no nibalizer 19:08:16 it can be reproposed for voting when he's ready to bring it back up 19:08:29 no im here 19:08:35 ahh, cool! 19:08:37 but yea we're having conversation in the spec 19:08:50 so lets just shelve this until we're ready to bring it back to the council 19:08:57 we can put it back to proposed for next week if you want, sure 19:09:11 i'll pull it from the agenda in the interim 19:09:12 thanks clarkb rcarrillocruz ianw_pto an jhesketh for feedback 19:09:20 yes pull it, i can add it back when it is time 19:09:44 ++ 19:10:02 #topic (Proposed) Priority Effort: Newton on Xenial (clarkb) 19:10:47 on the agenda you wrote: "Need to decide on Gearman strategy then we can work up a small spec." 19:11:14 ya so I sent mail to the infra list with a few options 19:11:53 the two basic ideas are go with what we did last time which no one seems to like much. Make every test job in JJB have a specific node type then zuul can run different tests for old and new branches 19:12:19 if we don't change zuul at all then the first option will result in ~1.5X the number of jobs we have right now. The second will result in ~2X 19:12:29 #link http://lists.openstack.org/pipermail/openstack-infra/2016-June/004479.html 19:12:43 if we use https://review.openstack.org/#/c/336311/ then we can keep the job registrations roughly equivalent to what we hvae now 19:12:44 (same thread linked in the action items topic earlier) 19:12:55 thanks 19:12:57 #link https://review.openstack.org/336311 19:13:11 Considering previous feedback I think we should go with the explicit job per image type with change 336311 in use with zuul 19:13:32 if there isn't strong opposition I will throw that into a spec this afternoon so we can make it official like. Also open to other ideas that people like more 19:13:34 i don't know what our current job registration max is -- i think/hope the mass_do change made things better there -- but i'd rather not find out this way, so i like 336311. 19:14:12 i haven't reviewed the diff, but the suggestion in the commit message is at least very compelling 19:14:34 jeblair: we have also cleaned out about 1300ish unused jobs 19:14:42 which should help keep us in a more reasonable place 19:14:48 nice! 19:15:05 by gettign a little more judicious about what jobs are included in some of the more common job-groups 19:15:18 yes thank you AJaeger for pushing on that 19:15:47 +1 19:16:55 keep in mind that python-jobs has fewer jobs now... 19:17:12 anyways I don't hear dissent or more better ideas so will go with explicit image type jobs and the zuul change as th eplan 19:17:18 #agreed Newton on Xenial spec will propose distro-specific job names with zuul-launcher improvement to make node labels optional in registrations 19:17:32 that look right? 19:17:49 it does to me 19:18:03 lftm 19:18:06 *lgtm 19:18:20 * fungi read that as "looks fine to me" ;) 19:18:20 I thought you were going with 'looks fine to me' 19:18:28 #topic Barcelona summit talk submissions (jhesketh) 19:18:30 and I was thinking clarkb you trendsetter you 19:18:41 This was just a reminder the deadline is coming up if anybody wants to work on a proposal 19:18:45 #link http://lists.openstack.org/pipermail/openstack-infra/2016-June/004416.html 19:18:55 yep, thx for reminding 19:19:02 Possibly the easiest way is to start a new etherpad and share on the list 19:19:15 jhesketh: newer than this? https://etherpad.openstack.org/p/barcelona-upstream-openstack-infa 19:19:40 i think we can use the same etherpad, just reorg it better 19:19:42 I think we're doing ok with this one from pabelanger's initial email 19:19:48 pabelanger: yeah 19:19:55 that's what we did last time around 19:19:58 worked well I think 19:20:08 did anyone reach out to thingee to see if lightning talks are a thing this time around? 19:20:17 mtreinish and i are putting in one to the upstream dev track for the "firehose" spec (whereby i actually mean mtreinish has done all the work so far and i've been slacking, so i need to put something together on my end asap) 19:20:32 fungi: heh 19:20:34 fungi: great 19:20:35 pleia2: yes, session is in 19:20:37 I'm interested to get some feedback from crinkle, rcarrillocruz on infracloud. See if there is interest to do a talk on that 19:20:45 Sure I didn't realise the intention was to put abstracts in there but that works (rather than talk ideas) 19:20:47 fungi: to be fair everything I've done has been incomplete too :) 19:20:50 pabelanger: yup, just wrote it down my insterest 19:20:55 thingee: cool, how should we submit proposals for that? 19:20:56 pleia2: I should send that email. was distracted with leadership training then fourth of july stuffs 19:20:58 mtreinish: story of my life 19:21:02 thingee: yes, thank you :) 19:21:04 i'm cool working with you crinkle and whoever on writing it down 19:21:10 * thingee makes to do item now 19:21:48 rcarrillocruz: sure 19:22:03 okay, so was this a good sync-up/redirect to the thread and etherpad, or do we need to go deeper in th emeeting? 19:22:08 jhesketh: ^ ? 19:22:28 I'm happy to work on it this week 19:22:30 #link https://etherpad.openstack.org/p/barcelona-upstream-openstack-infa 19:23:21 fungi: I think let's work on it in the pad and on the list 19:23:33 jhesketh: great--thanks for bringing it up! 19:23:34 pabelanger: I'll come up with a title for the infra beginners talk and we can collaborate on that over the next few days 19:23:51 #topic What is the current status of the gerrit its-storyboard plugin? (anteaya) 19:24:03 fungi: well zaro isn't here that I can see 19:24:16 so perhaps we can skip to the next item? 19:24:43 well, one thing i can tell you is that puppet probably accidentally reverted his alterations on review-dev again back on june 30 because of a bug we have where groups weren't getting expanded 19:25:06 fungi: I saw that yeah, I'll remind him to reconfigure when he returns 19:25:11 he might still be on holiday 19:25:16 i added mordred's recommended workaround yesterday (adding everything from the disabled group in git to our emergency file for now) 19:25:25 oh nice 19:25:25 but mordred is working on a more properish solution 19:25:27 I think https://review.openstack.org/#/c/330925/ is safe to be un-WIP'd, btw 19:25:30 pleia2: thanks 19:25:31 wonderful 19:25:47 I'm on holiday for the next few days but I've merged the patch that was waiting for 19:26:04 so if anyone needs to pass that on... there you go :) 19:26:10 Zara: thanks for that update, I'll share that with zaro upon his return 19:26:16 fungi: yah. I will write that up soonish 19:26:18 thank you, will pass it along 19:26:18 i guess we can just move on to the other sb topic you've proposed? 19:26:23 sure 19:26:30 #topic StoryBoard comments, editing/deleting allowed or no? (anteaya) 19:26:47 #link http://docs.openstack.org/infra/storyboard/webapi/v1.html#put--v1-stories--story_id--comments currently the StoryBoard api allows for editing and deleting comments 19:26:54 so the api allows one to edit or delete a comment 19:26:58 #link https://review.openstack.org/333418 19:27:06 #link https://review.openstack.org/332208 19:27:10 the description says update for both, but the second one is the delete action 19:27:13 #link https://review.openstack.org/333409 19:27:19 I wanted to hear folks opinion on this 19:27:34 personally I'm not a fan of being able to edit or delete a comment 19:27:42 create yes, not other actions 19:27:51 anyone else care to share their thoughts? 19:27:54 we do not allow deleting comments in gerrit 19:28:03 I don't think we should allow deletion 19:28:07 I am in general agreement that for us deleting things like that is bad 19:28:16 i agree. if anything, it should be admin only. 19:28:22 i'd like it to at least be configurable so that we can disable that behavior (except maybe for admins) 19:28:26 although I could certainly see other sb users having a different point of view on that 19:28:28 I think editing comments was originally requested on the nova bugs team etherpad 19:28:28 It would be confusing to post something to StoryBoard then delete it, only to have it replicated to Gerrit. 19:28:29 yah - what fungi said 19:28:29 admin only, yes 19:28:33 Zara: indeed 19:28:39 sometimes you just need to delete stuff 19:28:43 have we ever had to delete with spam or disrespectful comments? 19:29:05 is there any intention to duplicate StoryBoard comments to Gerrit? 19:29:13 my concern is that altering comments (the historical record) bifurcates discussion between those who have previously read them and those who are reading them for the first time 19:29:14 * SotK doesn't think that would be hugely useful 19:29:20 fungi: ++ 19:29:28 SotK: we don't do that with launchpad 19:29:42 SotK: not to my knowledge, no - I was mostly mentioning as a point of "we have a ton of comments over there and don't allow deletion" 19:29:42 okay, now I understand 19:29:48 the suggested implementation allows comment history to be retrieved 19:30:01 i don't think we need sb to echo gerrit comments or vice versa 19:30:03 Zara: if you know to retrive it 19:30:14 * SotK should've mentioned bkero in that 19:30:25 Zara: I think not knowing where to look would again lead to the bifurcation fungi mentions 19:30:30 I'm fine with editing if the old version remains (so that edit doesn't become "you delete it by replacing the comment with an empty string") 19:30:35 SotK: I didn't know if that was a desired feature or not. I could see it being, so I thought I would comment. 19:30:37 well, more "not knowing to look" 19:30:50 fungi: fair 19:30:55 anteaya: the WIP UI patch I sent allows anyone to see the full history of an edited comment 19:31:17 #link https://review.openstack.org/#/c/333418/ 19:31:33 SotK: I think as fungi said that at the very least it should be configurable to have that as the default, or disable the editing features 19:31:35 and we now keep history of any comments that are edited via the API, which is better than it was a couple of weeks back 19:31:53 fungi, author's remorse, spam, legal requests all are good reasons to allow deletion 19:32:10 well if an admin needs to delete spam comments I would hope the history can be cleared too 19:32:28 reed: there are non-regular-user ways of handling those in extreme cases 19:32:34 otherwise we are in the same problem with the wiki spam continually picked up by search engines even after it is deleted 19:32:44 reed: yes, though it's currently by request on lp, so i don't see lack of general deletion support for users as something which would block our adopting storyboard 19:32:53 ++ 19:32:57 ++ 19:33:40 yeah, we do still have access to the database, after all 19:33:43 by request seems like the most sensible way to do deletion, if it is done at all 19:33:46 and the goal at this phase is to only identify things which prevent us from moving projects to storyboard, not poll them for ideas on how to make storyboard superior to what they're currently using 19:34:16 right now I am leaning admin only on edit and delete on comments and if so then I don't think having a history is helping 19:34:18 it will be trivial for a DB admin to delete the history of a comment incidentally, and easy to write a patch to make the API do it if that is the intended behaviour 19:34:30 unless all the history says is "deleted by admin" 19:34:36 SotK: yeah, that's what I gathered from looking at the schema 19:34:50 yeah, i'm not particularly concerned about occasional deletion requests being handled with a mysql query. we already do that for, e.g., paste.o.o 19:35:09 yes, in my experience, the main reason to allow deletion for admins in a case like this is for legal reasons. and in that case, we would not want to make history available. 19:35:43 as a user, I like being able to edit things. 19:36:02 Zara: +1 19:36:04 As a user I like being able to see that a message was edited though, especially if I am reviewing a thread 19:36:07 as a consumer of a long standing comment stream, I like to have an accurate history 19:36:12 Not that I need to see the content of that history. Just edited=1 19:36:32 that is a good compromise ^ 19:36:42 I think it's important to continue our policy that once it's public, it's public, and there are no take-backs 19:36:44 Otherwise I will review an old thread and might think I've gone crazy from mis-remembering because someone altered history silently 19:36:48 mordred: +! 19:36:49 because that is true whether you think it is or not 19:36:54 and +1 19:36:57 though if you're following stories via e-mail update, you would need some indication that had happened (especially in a particularly long story) 19:37:19 does anyone think editing is important? 19:37:34 i believe editing should be a thing, thinking of a user accidentally putting creds or something when pasting errors, logs, etc 19:37:40 jeblair: I do not 19:37:46 this is the WIP UI btw: http://docs-draft.openstack.org/18/333418/3/check/gate-storyboard-webclient-js-draft/808fe8a//dist/ 19:37:55 i do not. the arguments i've seen so far are "it makes some users feel good that they can correct their typos" and "people who use popular web forums are used to being able to edit comments: 19:37:56 rcarrillocruz: we have actually explicitly refused to delete such mistakes in the past 19:37:59 rcarrillocruz: that's the thing -- it's a false sense of security there. people will have already received those in email. 19:38:02 rcarrillocruz: well it is the same situation if you do that in gerrit or launchpad or paste or etherpad now 19:38:03 yah 19:38:06 what jeblair said 19:38:07 this is a story that has been edited via the wip if anyone wants an example: http://docs-draft.openstack.org/18/333418/3/check/gate-storyboard-webclient-js-draft/808fe8a//dist/#!/story/24 19:38:31 I think that editing is an important feature for admins to have, but I generally like the idea that discussion pieces are immutable 19:38:43 s/editing/removal/ 19:38:45 as an admin, i don't want editing. i want, at most, deleting 19:38:53 (and i'm okay if the way to do that is a database) 19:38:53 bkero: well as has been pointed out admins have access to the db 19:39:09 jeblair: as long as its a simple db edit 19:39:18 and the schema is cleanly designed to make it safe and easy to delete a comment 19:39:24 So we're only discussing the ability for a user to edit posts then 19:39:32 but i don't think user self-editing should be a thing -- it doesn't do what people will think it does, and it encourages confusion in messages 19:39:38 bkero: I'm dicussing the api 19:39:59 bkero: right now the api allows any registered user to edit and delete comments 19:40:14 okay 19:40:26 bkero: thanks for clarifying 19:40:53 So is the proposal a toggle to remove 'UD' from the API's CRUD? 19:40:54 if notifications by email send the whole comment, then yeah, mistake has already shipped 19:41:28 bkero: well I hadn't gotten as far as proposing, mostly I wanted to hear others opinions and I'm glad folks are offering them 19:41:40 rcarrillocruz: right 19:41:49 anteaya: I hope you can interpret them into something useful :) 19:41:55 * SotK still thinks we should talk to markus_z about this, given he was the one who initially expressed a desire for this :) 19:42:00 agreed. 19:42:06 so i see your point jeblair 19:42:09 well I'm hoping fungi comes up with something by meeting's end 19:42:28 bkero: but he is patient to his credit, and conversation is still underway 19:43:16 SotK: I think gathering infra opinons at this point is useful, as infra has to maintain it as well as already has policy in place with other tools 19:43:38 no sense offering a project an option that goes against what already exists as infra policy 19:44:29 yes, so markus_z was proposing this as something that would prevent moving nova off lp? (given that lp lacks this feature too) 19:44:44 I don't think so; this was some time ago 19:44:48 fungi: noone knows, this was an artifact in an etherpad 19:44:52 okay 19:44:57 he was away then I was away 19:45:02 it was more a list of features that a preferred task-tracker would have. 19:45:05 so I haven't talked to him about it yet 19:45:09 there were IRC logs too, I'll see if I can find them 19:46:14 moving storyboard migration along is very important, and we have no other topics proposed this week, so as far as i'm concerned we can take the remaining 15 minutes to continue discussing this if needed 19:46:23 fungi: thanks 19:46:31 Zara: have you a link to the etherpad? 19:47:07 but I'd take it as more representative of a viewpoint of various potential users, and I don't know how big that group is yet 19:47:25 umm, I'm hesitating to go that far 19:47:48 it could just be one person and end up as a note in an etherpad 19:47:55 etherpad: https://etherpad.openstack.org/p/nova-bugs-team 19:48:28 line 119 19:48:35 #link https://etherpad.openstack.org/p/nova-bugs-team 19:48:50 :) well we know it's at least 3 of us. so I'd want to be clear on the reasons behind policy, if it goes that way 19:49:01 by the same token I'm not a fan of rating comments either 19:49:02 iirc the list came from the nova bugs team's discussions about desired features in a task tracker 19:49:08 * SotK isn't a fan of that either 19:49:20 a comment is a comment, if folks want to disagree with me, say so in a comment 19:49:42 yeah, so the definition of "requirement" there must differ from what i think is commonly accepted as its meaning 19:49:44 okay so this is useful, thank you 19:49:53 it looks like a feature wishlist 19:49:55 line 127 is markus_z's order of priorities for it 19:49:57 fungi: yeah 19:50:12 well wishlist is nice 19:50:36 and it is great markus took the time to offer some feedback and put some thought into it 19:50:46 what we need is for markus_z to put together a list of missing features in sb that need to be implemented to avoid a regression for his (and nova's in general) use of lp bug tracking 19:51:01 my question once the api docs all have examples is, if we move to storyboard tomorrow would you be able to get work done 19:51:35 and I'll be paying attention to anyone who says they can't get their work done on storyboard as it is right now and find out what more they need 19:51:44 while i appreciate the ideas and suggestions about what else a task tracker _could_ do, at this phase we need to focus on what it _must_ do for us to switch to it and not muddy that discussion with arbitrary wishlist items 19:51:55 yeah, that etherpad was created before the last summit. it wasn't intended as a list of storyboard requirements 19:51:59 fungi: yeah, thank you 19:52:03 okay great 19:52:05 given that 19:52:07 http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-03-02.log.html#t2016-03-02T11:38:09 is the IRC discussion from around that list 19:52:27 can we come to agreement on how to address the current api comment features? 19:52:41 we have devs willing to help implement what we'll absolutely need in sb, and i really don't want to end up with conflicting directives from our end making it harder for them 19:52:58 I am in the disable edit and delete and see how far we get with db queries by admins when requested to do so 19:53:52 yes, so i think from the "can openstack use sb now?" perspective, being _able_ to edit/delete comments beyond admin database queries is not relevant for us 19:54:18 and if sb is going to expose that ability for some deployments, we would very much like to be able to disable it in our deployment 19:55:16 which of course means disabling that part of the api since the web interface is just an api client 19:55:38 I agree with that assessment 19:56:01 * SotK will send a patch to that effect soon-ish then 19:56:03 anyone here disagree with that position? 19:56:32 that sounds reasonable to me 19:56:34 it's just my opinion, though i feel like it reflects the opinions of others on the team who have opinions on it 19:56:36 fungi: i agree with that position 19:56:55 agreed 19:57:21 #agreed OpenStack should not need the ability for task tracker users to edit and delete comments, but would like the ability to disable that if it becomes a feature 19:57:33 thank you 19:57:42 #topic Open discussion 19:57:45 thanks to everyone who participated in the discussion 19:57:48 we have two minutes and change 19:57:58 anyone know the status of ipsilon? 19:58:09 storyboard migration depends on it being in place 19:58:13 is anyone working on it? 19:58:18 smarcet should be back from his honeymoon now, so we wanted to pick that topic back up 19:58:30 any changes to our mid-cycle? 19:58:37 seems pretty quiet 19:59:00 pabelanger: what sort of changes are you anticipating? 19:59:11 i don't think dates will change 19:59:14 delete/edit comments shouldnt be allowed IMHO. 19:59:19 agenda there was an etherpad from nibalizer iirc 19:59:24 sorry was a bit late there. 19:59:28 notmorgan: thanks for reading the backscroll 19:59:54 fungi: nothing, wanted to see if zuulv3 and infracloud were the topics of choice 20:00:02 okay, we're out of time. thanks everyone! 20:00:07 thank you 20:00:08 #endmeeting