20:01:27 #startmeeting tc 20:01:28 Meeting started Tue Sep 27 20:01:27 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:30 o/ 20:01:32 The meeting name has been set to 'tc' 20:01:37 Our agenda for today: 20:01:39 hi 20:01:41 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:41 * flaper87 does the startmeeting dance 20:01:48 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:01:57 #topic PTL election results 20:02:00 o/ 20:02:11 o/ 20:02:14 We have a number of things to merge to officialize recent PTL election round 20:02:24 * Update projects.yaml with results of the PTL elections (https://review.openstack.org/376059) 20:02:49 This one officializes the results. Roland Hochmuth's email is likely wrong though 20:03:08 I guess this needs a new PS 20:03:09 I'd like to preserve the election officials +1 on this one so we can merge it now, so... maybe fix Roland's email in a subsequent patch ? 20:03:11 I can prepare a follow-up to revert that part of the change if we want to approve this one 20:03:17 there were some other questions in there from dhellmann 20:03:22 dhellmann: that'd be great 20:03:25 it did seem like a large amount of email changes for people 20:03:34 anyone know the source of that? 20:03:42 tonyb_: ^ 20:03:44 ? 20:03:45 Roland's email change is probably wrong, and Kirill said he would rather have his other address listed 20:03:46 I'm fine with merging then fixing email addresses. 20:03:51 I assumed they were being made consistent with the gerrit emails for the nominations 20:03:56 I asked tonyb to do a new PS but he wasn't awake 20:04:03 yeah, merge then fix seems OK 20:04:16 dhellmann: thx for preparing a subsequent patch 20:04:18 o/ 20:04:26 doing a new PS during the meeting and merging at the end should be fine 20:04:45 tonyb might still be asleep :) 20:05:20 OK, approving now then 20:05:23 annegentle: tonyb sleeps? That's news to me :) 20:05:29 ttx: https://review.openstack.org/378007 20:05:31 #link https://review.openstack.org/378007 20:05:35 oh, I misread dhellmann's comment. He said he'd work on a follow-up patch, not on a follow-up PS 20:05:38 mtreinish lightly I'm sure :) 20:05:58 let's quick-review dhellmann's followup and merge it as typo fix 20:06:12 done 20:06:14 I only fixed 2 of them that were confirmed wrong. Should I reset the others, too? 20:06:30 dhellmann: no, the other email address changes have all been +1ed 20:06:33 ok 20:06:34 by their owners 20:07:16 ok typo fix approved too 20:07:21 next up 20:07:23 * Confirm Piet Kruithof as PTL for UX (no patch needed) 20:07:32 Following our discussion from last week, we should officialize Piet's PTLship now 20:07:36 ++ 20:07:47 No change needed since he was already there 20:07:50 heh - "officialize" 20:07:53 so, voice vote? 20:07:53 but would like to log it in meeting logs 20:08:10 yes, let's do vote 20:08:12 * mordred thinks Piet is neat 20:08:22 ++ 20:08:39 #startvote Appoint Piet Kruithof as UX PTL for Ocata? yes, no, abstain 20:08:40 Begin voting on: Appoint Piet Kruithof as UX PTL for Ocata? Valid vote options are yes, no, abstain. 20:08:41 Vote using '#vote OPTION'. Only your last vote counts. 20:08:44 #vote yes 20:08:45 #vote yes 20:08:45 #vote yes 20:08:46 #vote yes 20:08:48 #vote yes 20:08:49 #vote yes 20:08:51 #vote yes 20:08:53 #vote yes 20:08:58 #vote yes 20:09:05 30 seconds left... feels like Grizzly all over again 20:09:16 #vote yes 20:09:29 #vote yes 20:09:39 #endvote 20:09:40 Voted on "Appoint Piet Kruithof as UX PTL for Ocata?" Results are 20:09:41 yes (11): ttx, mestery, mtreinish, dtroyer_zz, thingee, russellb, sdague, mordred, dims, dhellmann, flaper87 20:09:53 * Remove Astara from governance (https://review.openstack.org/376609) 20:10:02 ttx: that takes me back to back in the day for sure 20:10:04 This patch removes Astara from governance, got its previous PTLs +1s 20:10:23 lgtm 20:10:36 anteaya raised that the file is badly named, since those are not necessarily all retired projects 20:10:38 most of the core contributors, too, it looks like 20:10:42 but then I can't remember why we list those in a file 20:10:52 do the election tools look at that file? 20:11:20 I think it was something about keeping projects for ATC elections for the time they were in 20:11:31 like if you removed a project just before elections 20:11:33 I thought it had something to do with ensuring that we don't invalidate electorate rolls 20:11:35 right 20:11:40 i think the election tools don't _yet_ look at that file and should 20:11:46 ah 20:11:47 and to also keep track of "removed" projects, I believe 20:11:52 sure, there's git but 20:11:58 I think it's good to track for docs to know. 20:12:09 and our future selves not to have to grep git logs? 20:12:13 does not have dates etc 20:12:17 anyway, I'd rather merge that one so we record the decision there, and merge the file rename afterwards. Lets us keep the Astara ex-PTLs vote in the review 20:12:18 worth noting, we've also had official projects retire repos, which mighth should have gone into something similar 20:12:23 dims : good point 20:12:30 fungi ah, yeah probably 20:12:48 as there were recent contributors to, e.g., one that fuel retried and dropped from their deliverables list recently who hadn't contributed to other official repos 20:12:58 s/retried/retired/ 20:13:03 OK, we have the votes to pass that one, objections ? 20:13:22 no objections 20:13:23 let's take it and figure out what we need to do with the election tools before we change the filename 20:13:29 +1 dhellmann 20:13:30 ++ 20:13:32 yep 20:13:33 +1 20:13:37 yes 20:13:38 approved 20:13:46 NB: As a side-effect I reassigned the Astara design summit slot to another project 20:13:56 (Storlets) 20:13:58 so they don't have any sessions? 20:14:22 If someone there asks me some I could make that happen 20:14:24 iiuc, they were hoping to use time at the summit to coordinate the hand-off 20:14:38 markmcclain or ryanpetrello would know 20:14:43 dhellmann: ok, we'll take that offline 20:14:47 ++ 20:14:51 * Decide future of Security and OpenStackSalt project teams 20:14:58 So we had a thread 20:15:02 #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/104170.html 20:15:14 For Security, the consensus on the thread seems to be that we should keep the team 20:15:23 I think the crisis uncovered issues, but that the team is committed to fixing them 20:15:24 ttx : i pinged the openstack-salt folks 20:15:34 dims: one at a time 20:15:40 I also joined the security team at their meeting last week 20:15:41 #link http://eavesdrop.openstack.org/meetings/security/2016/security.2016-09-22-17.00.log.html 20:15:54 and yes, I agree with ttx's assessment 20:15:58 it feels like the security team are adjusting to be more aligned 20:16:16 ++ 20:16:22 to note that this is the second time the security team has been leaderless at the time of election. 20:16:25 * fungi is relieved not to need to decide where the vmt moves next 20:16:36 fungi: I've got room in my backyard maybe 20:16:36 but happy to see people are interested in helping the security team 20:16:38 fungi :) 20:16:41 this sounds good to me 20:16:54 thingee : that's true. there were apparently some extenuating personal circumstances, combined with confusion, this time. 20:17:00 thingee: good to raise that point 20:17:04 fungi: honestly, making vmt a workgroup of the TC might be more appropriate anyway 20:17:10 Glad to see the team moving forward. Hopefully this won't happen in the future 20:17:25 ttx: do we need to formally vote on having hyakuhei stay on as ptl, like we did with Piet? 20:17:30 yes, making VMT separate (to better reflect how the team works) can be done separately 20:17:33 sdague: i'm open to discussing that with the other vmt members 20:17:34 does the tc have workgroups or committees? 20:17:34 dhellmann: yes 20:17:34 sdague: wasn't a separate thing before? I thought we combined them not that long ago 20:17:45 anteaya: not really 20:17:47 mtreinish : it used to be part of the release team 20:17:50 ah, ok 20:17:53 ttx: I didn't think so 20:17:57 that;s what I was thinking of 20:18:12 mtreinish: we got evicted ;) 20:18:13 anything we can't automate we're spinning out into its own team ;-) 20:18:18 ttx: anteaya we've had in the past. Like the PTG "team". More like a sprint/temporary team, though. 20:18:36 #startvote Keep Security team and appoint Rob Clark as PTL for Ocata? yes, no, abstain 20:18:36 Begin voting on: Keep Security team and appoint Rob Clark as PTL for Ocata? Valid vote options are yes, no, abstain. 20:18:37 Vote using '#vote OPTION'. Only your last vote counts. 20:18:43 flaper87: yes, more like subsets of members :) 20:18:45 I don't recall a PTG team 20:18:45 #vote yes 20:18:48 #vote yes 20:18:49 #vote yes 20:18:50 #vote yes 20:18:53 #vote yes 20:18:53 anteaya: project team guide #acronymoverload 20:18:56 #vote yes 20:18:57 #vote yes 20:18:58 #vote yes 20:19:02 #vote yes 20:19:05 ttx: oh, okay thanks 20:19:09 30 more seconds 20:19:21 #vote yes 20:19:37 #endvote 20:19:38 Voted on "Keep Security team and appoint Rob Clark as PTL for Ocata?" Results are 20:19:39 yes (10): ttx, mestery, mtreinish, dtroyer_zz, russellb, sdague, dims, dhellmann, flaper87, johnthetubaguy 20:20:22 OK, Salt now 20:20:22 dims: could you give us an update there ? 20:20:22 heh sorry I keep missing the vote 20:20:22 I will blame my cats 20:20:40 damn cats 20:21:05 cats are definitely anti-democratic 20:21:05 annegentle: I also blame your cats 20:21:13 talked to a few openstack-salt folks 20:21:15 #link https://review.openstack.org/#/c/377906/ 20:21:19 * flaper87 blames all cats 20:21:28 annegentle: heh, well it's one less yes than before so you're not alone :) 20:21:31 they are needy and all 20:21:32 looks like they are not sure what they want to to 20:21:36 to do 20:21:43 On one hand they acknowledged the issues, but there was also a feeling that community alignment was secondary to the "usefulness" of the project 20:21:49 then +1ed the removal from governance 20:22:05 several folks already chimed in on the review 20:22:06 dims nice work then 20:22:08 there 20:22:11 they somehow think they have to move to github 20:22:28 i have been guiding them that it's ok to leave repos here if they wish 20:22:30 anteaya : I think that was cleared up in the last comment 20:22:40 dims: do they know that being removed from governance means they can continue to use all our services 20:22:41 dims: looks like a plan. 20:22:51 dhellmann: okay 20:22:52 anteaya : yes, i made it clear 20:22:55 * mordred would be happy to visit them in prague to clear things up 20:23:06 dims: great thank you 20:23:26 mordred: sounds like a good idea 20:23:30 for what it's worth, that confuses a bunch of people. I think I had at least 2 conversations in NYC having to explain that to folks. I'm not sure how we make it more clear. 20:23:31 mordred : +1 if you can catch some of the higher ups, that would help too i think 20:23:39 sdague : true 20:23:50 * thingee is back - bad lag 20:24:14 sdague : add the feature to gerrit to make renaming a repo easier so we can use a separate namespace again? 20:24:16 well renaming the file to removed from goverance instead of retired should help a bit 20:24:16 sdague: that does seem to surprise everyone 20:24:21 sdague: it's something we lost when we removed stackforge branding. "Unofficial" doesn't have the same effect 20:24:21 mordred : ttx : i think post-acquisition they are changing focus/strategy too 20:24:32 more docs? Not sure where though. 20:24:34 dims: yes, I gathered that much from change of tone 20:24:37 dims: yah, I could certainly see that 20:24:52 sdague: fwiw, I've had that conversation many times too. I don't know how to make it better as of now, though 20:24:52 i am sad, but can't help it 20:25:13 dims: you did a good job communicating 20:25:15 dims: thank you 20:25:33 thanks anteaya 20:25:43 Looks like they should be removed while they reassess their situation 20:25:47 i too am struggling to figure out how we make a clearer message about the lack of relationship between being an official team and being able to host in our infrastructure/ci 20:25:50 ttx : yes 20:25:53 #link https://review.openstack.org/#/c/377906/ 20:25:58 it's a huge issue, i hear it all the time 20:26:06 oh, do we want this patch to be updated to move them to the retired file? 20:26:07 russellb: ++ 20:26:08 it really confuses people trying to figure out what is openstack 20:26:29 russellb: because they should be asking "who" rather than "what" maybe? 20:26:32 dhellmann: good catch, I think we do 20:26:35 dims: ^ 20:26:50 fungi: i don't thing consumers care about who all that much 20:26:51 ah, yes 20:27:10 anteaya already alerted me to that, yes, i can fix this one up when the astara one merges based on what we decide there 20:27:10 * devananda gets off a flight and takes a seat in the back of the room 20:27:16 fungi: and we don’t really get to tell people which questions they should ask…they just ask the questions they have = ) 20:27:24 i tend to agree with the argument that all of this primarily benefits the dev community, and not everyone else 20:27:33 jbryce: sure, but we can explain that some questions are based on false assumptions 20:27:35 dims: I'd rather move it to the retired file and then rename the file 20:27:35 our job got easier, everyone else got more confused 20:27:40 damn the netsplit is killing me 20:27:41 dims : if you want to just add it in a follow-up, we'll retain the existing votes from the team 20:27:44 russellb: +100 20:27:46 dims : if you want to just add it in a follow-up, we'll retain the existing votes from the team 20:27:50 dhellmann : sounds good 20:27:53 jbryce russellb: +1 20:27:57 just some final ranting before i drop off the TC, i guess.. 20:28:02 ok, let's merge that one and then move 20:28:07 russellb: ow no! 20:28:18 OK approved 20:28:32 dims: if you submit the other one we can quick-merge it 20:28:44 Let's move on to next topic 20:28:49 ttx : ack after this meeting 20:28:53 #topic Tag neutron-lib as tc-approved-release 20:28:56 * markvoelker lurks in case there are questions on this one, but sees an awful lot of RC+1's already... 20:29:01 #link https://review.openstack.org/371777 20:29:10 I think this one if a no-brainer, since it's more the result of code split than anything new. 20:29:23 But yes, interesting precedent to set 20:29:23 yeah, we should have done this when the new repo was added, really 20:29:24 markvoelker: thanks for clarifying things there 20:29:26 yep 20:29:33 flaper87: sure thing 20:29:34 ttx: fwiw, I still think there is still some confusion around the purpose of that tag 20:29:41 any last-minute comment before we approve ? 20:29:43 we should look at glance_store, ironic-lib, etc. too 20:29:44 I'm not sure how to clean it up though 20:30:02 dhellmann: glance_store is actually being looked at right now as a matter of fact 20:30:07 good 20:30:08 mtreinish: https://review.openstack.org/#/c/374027/ 20:30:11 markvoelker: great 20:30:16 markvoelker : thanks for cleaning this up :-) 20:30:20 mtreinish: sdage has a patch that should help 20:30:22 mtreinish: we should do a "5 top myths about the TC" lightning talk 20:30:29 ttx: lol 20:30:33 sort of wondering if that interpretation also makes most of oslo tc-approved-release 20:30:44 sdague: yep that would do it :) 20:31:04 sdague: heh, although there might also be confusion about what defcore means, but that's something else 20:31:05 ttx: That's actually not a bad idea. ;) 20:31:23 ok, approving now based on existing votes 20:31:33 fungi: maybe, that rabbit hole seems to go a long way. I think the current process of defcore telling us what they need to be effective should be the model 20:31:35 ttx: go go go 20:31:39 but yes, that raises questions for Oslo, ironic-lib or glance_store 20:31:39 ttx: heh, 1 myth per minute :) 20:32:13 sdague: just seems like neutron-lib is not useful outside neutron and so listing it as part of tc-approved-release becomes redundant. but eh, more important battles to be fought 20:32:32 OK, next topic... 20:32:36 #topic Write down OpenStack principles 20:32:36 ttx: sure, but I think our process here works. Because markvoelker and team can make the calls about what they think are needed to enforce the TM 20:32:50 #link https://review.openstack.org/357260 20:32:50 fungi : I think the point is that the library does (or will) implement capabilities expressed through the API, and we want our implementation used 20:32:56 which makes it less likely that oslo is a good candidate to be added 20:32:58 So I think this reached a level where it's simpler to discuss future alterations as subsequent changes 20:33:00 * flaper87 liked jroll's comment 20:33:12 rather than wait forever for an hypothetical perfect version 20:33:17 can we have stars/favs/hearts on gerrit ? #halfjoke 20:33:21 Not saying the remaining comments do not have value, but I think it will be easier to discuss them on their own merits (and together with proposed wording changes) 20:33:34 The change has majority support now, so I'll approve it unless someone objects 20:33:35 * flaper87 agrees 20:33:50 "Perfection is the enemy of the good" 20:33:56 no objections here. I'd love to see some of these principles to be improved individually 20:34:01 flaper87: ++ 20:34:05 well, I'm a perfectionist, but also a pragmatist 20:34:12 flaper87 : agree 20:34:51 * flaper87 will rebase his "good fatih" patch as soon as this one lands 20:34:58 Thanks to mordred for writing the initial version, even if I ended up watering it down quite a bit 20:35:03 we can have that convo later too 20:35:13 thanks mordred and thanks ttx for addressing comments 20:35:32 alright, it's in 20:35:35 thanks to everyone. I think, as dtroyer_zz says in one of the comments, I'm quite excited to see what comes next 20:35:50 ttx: thank you for all your hard work on this 20:36:01 ++ 20:36:03 ++ 20:36:05 ++ 20:36:07 +1 20:36:10 thanks ttx 20:36:24 * flaper87 proposes a group hug 20:36:28 Thanks for the support everyone! 20:36:45 and... moving on before flaper87 reaches me 20:36:45 * dhellmann links arms with flaper87 20:36:53 #topic Create a project tag for zero-downtime upgrades 20:37:04 #link https://review.openstack.org/372686 20:37:08 dolphm: around ? 20:37:13 similar to other upgrade tags, this stuff is likely backend dependent, and we don't have good ways of capturing that 20:37:29 i don't have a solution necessarily, but just a note 20:37:40 I think it's a great idea to raise the bar here... which projects would be expected to pass that ? 20:37:50 so its mostly API based projects 20:38:02 I know OSIC is trying to help with getting more projects to zero downtime 20:38:03 I believe dolphm is mostly out today, not sure if he'll make it here 20:38:07 I think keystone is almost there 20:38:09 as a few noted in the comments already, we'll need some form of testing to reduce the risk of regression in that space 20:38:10 I was curious about which projects would have this, too 20:38:26 I suspect keystone would work on it 20:38:33 the test job implementation will be interesting 20:38:33 Glance likely 20:38:42 yeh, my biggest concern is that we have some reasonable validation here before we assert anything 20:38:49 I think the current work is around testing old and new APIs at the same time 20:38:49 ironic is working towards it as well 20:39:01 sdague: thats a fair point, we are premature on that front 20:39:02 yeah, moving this forward without a good way to validate it won't add much value 20:39:05 sdague: beyond validation, I'm concerned about regressing once you have it 20:39:09 I think you can build on grenade for the testing. 20:39:18 swift would pass, depending on the "control plane" wording 20:39:18 ttx: meaning? 20:39:19 just have to make it multinode 20:39:25 ttx: I meant validation as a way to avoid regression 20:39:33 SpamapS: we run grenade multinode already 20:39:34 and upgrade one node, test, upgrade the other, test. 20:39:34 test it and watch for failures 20:39:36 right, I know we are thinking about grenade testing old and new API nodes living side be side 20:39:51 devananda: ironic is working toward rolling upgrades, not zero-downtime, but that will be close and next :) 20:39:55 at least thats where I was thinking we would be going to validate zero downtime, in some sense 20:39:56 just to be clear 20:40:08 sdague: I think we could manually test when the tag is asserted, but it needs to be in the gate to avoid regressions 20:40:24 SpamapS: wouldn't that be rolling upgrade, not zero downtime? 20:40:25 ttx: oh, sorry, when I mean validation I mean something that's running all the time validating 20:40:28 agreed 20:40:32 So I fear that the tag is the easiest part of this :) 20:40:32 yeah, I'd like to see a requirement that the job already exist before the tag is added 20:40:37 ttx: honestly, we should test this in gate, to some extent 20:40:41 jroll: how would you characterize rolling upgrades, if not some of your ironic nodes are upgraded and others aren't? 20:40:45 mtreinish: Yes, but rolling is a precursor to 0-dt isn't it? 20:40:50 johnthetubaguy: we are in violent agreement 20:40:50 ttx: right, the tag seems premature in that regard 20:40:57 jroll: right - our path to no-downtime starts with rolling. but that's the goal AIUI. 20:41:06 SpamapS: not always, depends on your architecture really 20:41:08 sdague: maybe they want to use the tag as the carrot to motivate people to work on that ? 20:41:24 lets get a CI model for testing this, especially as the techniques currently being proposed are database triggers 20:41:25 ttx: johnthetubaguy violence is not good :D 20:41:43 which put logic in a place we don't really have test coverage 20:41:49 but all that said, I think it's a nice target to shoot at 20:41:54 agreed 20:42:01 so part of this is making clear rolling upgrades includes API downtime 20:42:11 that was causing some confusion in internal discussions 20:42:16 I guess I never really considered a scenario where rolling upgrades with downtime is a desired outcome of development. 20:42:29 johnthetubaguy: thanks, that's what i was missing i think 20:42:50 Yeah, I'll admit I missed that part too (API downtime in rolling upgrades) 20:42:55 SpamapS: short downtime is a heaps better than massive long downtime, thats where we were coming form before I believe 20:42:55 But yeah, in that case, one needs to have a monitoring system get involved to verify uptime. 20:43:03 johnthetubaguy: ack, just hadn't considered it. 20:43:29 Is there a team that is chiefly responsible for writing and maintaining tests that validate tags? 20:43:31 monitoring systems based on polling won't tell you that with any reliability 20:43:31 so I think the gate verification could just be mixed API nodes working together, thats the bit that would break 20:43:37 OK, so... do we want to wait until we have some plan around testing before we approve this tag ? 20:43:38 and, realize, there is still individual service server downtime in this model 20:43:44 ttx: that seems a good summary 20:43:48 like, does QA take up that charge or does the TC just evaluate per-project? 20:43:51 ttx: yes, let's wait for a more detailed plan 20:43:55 but it depends on the idea of having multiple API servers in a load balancer 20:43:57 ++ 20:43:57 ttx: yup 20:43:58 * SpamapS apologizes for being a little uneducated on the tags system 20:44:09 SpamapS : good question 20:44:16 #info That's a great idea, but we need to nail down testing before we approve the tag 20:44:20 each tag has a section that describes how it's applied 20:44:25 and who is responsible 20:44:31 so you are really running mixed API server versions in a load balancer against the same database 20:44:31 or is supposed to.. 20:44:33 i think it's on the shoulders of the projects who want to apply this tag to their deliverables to work out the testing for it 20:44:46 sdague: yeah, there is a dependency on a load balancer, which I am OK with, but thats non obvious in the tag's current form 20:45:07 fungi : right, I interpreted SpamapS' question as how do we know that has been done correctly? 20:45:18 fungi: +1, I guess it would be good to have one project that feels like they have done it, as a starting point 20:45:22 johnthetubaguy: yeh, that should probably in there, that also informs the model for testing 20:45:23 dhellmann: oh, thanks 20:45:31 fungi: right, as long as they can explain how their gate verifies it to those who apply the tags (presumably the TC), that would seem like the most distributed way to handle it. 20:45:34 sdague: yeah 20:45:40 right, whether that's add haproxy in devstack multi-node or what 20:45:41 SpamapS: dhellmann I think we've done it by linking infra/gate reviews so far 20:45:49 and by manually checking tests are in place 20:45:57 flaper87 : that works 20:46:10 because, honestly, I think the testing for this might be entirely orthoginal to the other upgrade testing we do, as it will be easier to test/debug ha-proxy - mixed API nodes for many things without the rest of the infrastructure 20:46:17 Sounds like the answer is that the TC does participate actively in the validation initially. 20:46:20 sdague: +100 20:46:57 I am not sure ha proxy is "good enough yet", I should really look into that 20:46:57 SpamapS: yeah 20:46:58