20:01:27 <ttx> #startmeeting tc
20:01:28 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:30 <SpamapS> o/
20:01:32 <openstack> The meeting name has been set to 'tc'
20:01:37 <ttx> Our agenda for today:
20:01:39 <russellb> hi
20:01:41 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:41 * flaper87 does the startmeeting dance
20:01:48 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:01:57 <ttx> #topic PTL election results
20:02:00 <mordred> o/
20:02:11 <mtreinish> o/
20:02:14 <ttx> We have a number of things to merge to officialize recent PTL election round
20:02:24 <ttx> * Update projects.yaml with results of the PTL elections (https://review.openstack.org/376059)
20:02:49 <ttx> This one officializes the results. Roland Hochmuth's email is likely wrong though
20:03:08 <flaper87> I guess this needs a new PS
20:03:09 <ttx> 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 <dhellmann> I can prepare a follow-up to revert that part of the change if we want to approve this one
20:03:17 <sdague> there were some other questions in there from dhellmann
20:03:22 <flaper87> dhellmann: that'd be great
20:03:25 <sdague> it did seem like a large amount of email changes for people
20:03:34 <sdague> anyone know the source of that?
20:03:42 <flaper87> tonyb_: ^
20:03:44 <flaper87> ?
20:03:45 <ttx> Roland's email change is probably wrong, and Kirill said he would rather have his other address listed
20:03:46 <annegentle> I'm fine with merging then fixing email addresses.
20:03:51 <dhellmann> I assumed they were being made consistent with the gerrit emails for the nominations
20:03:56 <ttx> I asked tonyb to do a new PS but he wasn't awake
20:04:03 <johnthetubaguy> yeah, merge then fix seems OK
20:04:16 <ttx> dhellmann: thx for preparing a subsequent patch
20:04:18 <thingee> o/
20:04:26 <flaper87> doing a new PS during the meeting and merging at the end should be fine
20:04:45 <annegentle> tonyb might still be asleep :)
20:05:20 <ttx> OK, approving now then
20:05:23 <mtreinish> annegentle: tonyb sleeps? That's news to me :)
20:05:29 <dhellmann> ttx: https://review.openstack.org/378007
20:05:31 <dhellmann> #link https://review.openstack.org/378007
20:05:35 <flaper87> 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 <annegentle> mtreinish lightly I'm sure :)
20:05:58 <ttx> let's quick-review dhellmann's followup and merge it as typo fix
20:06:12 <flaper87> done
20:06:14 <dhellmann> I only fixed 2 of them that were confirmed wrong. Should I reset the others, too?
20:06:30 <ttx> dhellmann: no, the other email address changes have all been +1ed
20:06:33 <dhellmann> ok
20:06:34 <ttx> by their owners
20:07:16 <ttx> ok typo fix approved too
20:07:21 <ttx> next up
20:07:23 <ttx> * Confirm Piet Kruithof as PTL for UX (no patch needed)
20:07:32 <ttx> Following our discussion from last week, we should officialize Piet's PTLship now
20:07:36 <flaper87> ++
20:07:47 <ttx> No change needed since he was already there
20:07:50 <edleafe> heh - "officialize"
20:07:53 <dhellmann> so, voice vote?
20:07:53 <ttx> but would like to log it in meeting logs
20:08:10 <ttx> yes, let's do vote
20:08:12 * mordred thinks Piet is neat
20:08:22 <dtroyer_zz> ++
20:08:39 <ttx> #startvote Appoint Piet Kruithof as UX PTL for Ocata? yes, no, abstain
20:08:40 <openstack> Begin voting on: Appoint Piet Kruithof as UX PTL for Ocata? Valid vote options are yes, no, abstain.
20:08:41 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:08:44 <flaper87> #vote yes
20:08:45 <ttx> #vote yes
20:08:45 <sdague> #vote yes
20:08:46 <dhellmann> #vote yes
20:08:48 <mtreinish> #vote yes
20:08:49 <dtroyer_zz> #vote yes
20:08:51 <russellb> #vote yes
20:08:53 <dims> #vote yes
20:08:58 <mestery> #vote yes
20:09:05 <ttx> 30 seconds left... feels like Grizzly all over again
20:09:16 <thingee> #vote yes
20:09:29 <mordred> #vote yes
20:09:39 <ttx> #endvote
20:09:40 <openstack> Voted on "Appoint Piet Kruithof as UX PTL for Ocata?" Results are
20:09:41 <openstack> yes (11): ttx, mestery, mtreinish, dtroyer_zz, thingee, russellb, sdague, mordred, dims, dhellmann, flaper87
20:09:53 <ttx> * Remove Astara from governance (https://review.openstack.org/376609)
20:10:02 <mordred> ttx: that takes me back to back in the day for sure
20:10:04 <ttx> This patch removes Astara from governance, got its previous PTLs +1s
20:10:23 <flaper87> lgtm
20:10:36 <ttx> anteaya raised that the file is badly named, since those are not necessarily all retired projects
20:10:38 <dhellmann> most of the core contributors, too, it looks like
20:10:42 <ttx> but then I can't remember why we list those in a file
20:10:52 <dhellmann> do the election tools look at that file?
20:11:20 <ttx> I think it was something about keeping projects for ATC elections for the time they were in
20:11:31 <ttx> like if you removed a project just before elections
20:11:33 <dhellmann> I thought it had something to do with ensuring that we don't invalidate electorate rolls
20:11:35 <dhellmann> right
20:11:40 <fungi> i think the election tools don't _yet_ look at that file and should
20:11:46 <dhellmann> ah
20:11:47 <flaper87> and to also keep track of "removed" projects, I believe
20:11:52 <flaper87> sure, there's git but
20:11:58 <annegentle> I think it's good to track for docs to know.
20:12:09 <annegentle> and our future selves not to have to grep git logs?
20:12:13 <dims> does not have dates etc
20:12:17 <ttx> 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 <fungi> worth noting, we've also had official projects retire repos, which mighth should have gone into something similar
20:12:23 <dhellmann> dims : good point
20:12:30 <annegentle> fungi ah, yeah probably
20:12:48 <fungi> 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 <fungi> s/retried/retired/
20:13:03 <ttx> OK, we have the votes to pass that one, objections ?
20:13:22 <dims> no objections
20:13:23 <dhellmann> let's take it and figure out what we need to do with the election tools before we change the filename
20:13:29 <dims> +1 dhellmann
20:13:30 <flaper87> ++
20:13:32 <ttx> yep
20:13:33 <johnthetubaguy> +1
20:13:37 <thingee> yes
20:13:38 <ttx> approved
20:13:46 <ttx> NB: As a side-effect I reassigned the Astara design summit slot to another project
20:13:56 <ttx> (Storlets)
20:13:58 <dhellmann> so they don't have any sessions?
20:14:22 <ttx> If someone there asks me some I could make that happen
20:14:24 <dhellmann> iiuc, they were hoping to use time at the summit to coordinate the hand-off
20:14:38 <dhellmann> markmcclain or ryanpetrello would know
20:14:43 <ttx> dhellmann: ok, we'll take that offline
20:14:47 <dhellmann> ++
20:14:51 <ttx> * Decide future of Security and OpenStackSalt project teams
20:14:58 <ttx> So we had a thread
20:15:02 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/104170.html
20:15:14 <ttx> For Security, the consensus on the thread seems to be that we should keep the team
20:15:23 <ttx> I think the crisis uncovered issues, but that the team is committed to fixing them
20:15:24 <dims> ttx : i pinged the openstack-salt folks
20:15:34 <ttx> dims: one at a time
20:15:40 <dhellmann> I also joined the security team at their meeting last week
20:15:41 <dhellmann> #link http://eavesdrop.openstack.org/meetings/security/2016/security.2016-09-22-17.00.log.html
20:15:54 <dhellmann> and yes, I agree with ttx's assessment
20:15:58 <sdague> it feels like the security team are adjusting to be more aligned
20:16:16 <mordred> ++
20:16:22 <thingee> 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 <mordred> fungi: I've got room in my backyard maybe
20:16:36 <thingee> but happy to see people are interested in helping the security team
20:16:38 <dims> fungi :)
20:16:41 <flaper87> this sounds good to me
20:16:54 <dhellmann> thingee : that's true. there were apparently some extenuating personal circumstances, combined with confusion, this time.
20:17:00 <anteaya> thingee: good to raise that point
20:17:04 <sdague> fungi: honestly, making vmt a workgroup of the TC might be more appropriate anyway
20:17:10 <flaper87> Glad to see the team moving forward. Hopefully this won't happen in the future
20:17:25 <dhellmann> ttx: do we need to formally vote on having hyakuhei stay on as ptl, like we did with Piet?
20:17:30 <ttx> yes, making VMT separate (to better reflect how the team works) can be done separately
20:17:33 <fungi> sdague: i'm open to discussing that with the other vmt members
20:17:34 <anteaya> does the tc have workgroups or committees?
20:17:34 <ttx> dhellmann: yes
20:17:34 <mtreinish> sdague: wasn't a separate thing before? I thought we combined them not that long ago
20:17:45 <ttx> anteaya: not really
20:17:47 <dhellmann> mtreinish : it used to be part of the release team
20:17:50 <mtreinish> ah, ok
20:17:53 <anteaya> ttx: I didn't think so
20:17:57 <mtreinish> that;s what I was thinking of
20:18:12 <fungi> mtreinish: we got evicted ;)
20:18:13 <dhellmann> anything we can't automate we're spinning out into its own team ;-)
20:18:18 <flaper87> ttx: anteaya we've had in the past. Like the PTG "team". More like a sprint/temporary team, though.
20:18:36 <ttx> #startvote Keep Security team and appoint Rob Clark as PTL for Ocata? yes, no, abstain
20:18:36 <openstack> Begin voting on: Keep Security team and appoint Rob Clark as PTL for Ocata? Valid vote options are yes, no, abstain.
20:18:37 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:18:43 <ttx> flaper87: yes, more like subsets of members :)
20:18:45 <anteaya> I don't recall a PTG team
20:18:45 <dhellmann> #vote yes
20:18:48 <flaper87> #vote yes
20:18:49 <dtroyer_zz> #vote yes
20:18:50 <dims> #vote yes
20:18:53 <sdague> #vote yes
20:18:53 <ttx> anteaya: project team guide #acronymoverload
20:18:56 <mtreinish> #vote yes
20:18:57 <ttx> #vote yes
20:18:58 <johnthetubaguy> #vote yes
20:19:02 <russellb> #vote yes
20:19:05 <anteaya> ttx: oh, okay thanks
20:19:09 <ttx> 30 more seconds
20:19:21 <mestery> #vote yes
20:19:37 <ttx> #endvote
20:19:38 <openstack> Voted on "Keep Security team and appoint Rob Clark as PTL for Ocata?" Results are
20:19:39 <openstack> yes (10): ttx, mestery, mtreinish, dtroyer_zz, russellb, sdague, dims, dhellmann, flaper87, johnthetubaguy
20:20:22 <ttx> OK, Salt now
20:20:22 <ttx> dims: could you give us an update there ?
20:20:22 <annegentle> heh sorry I keep missing the vote
20:20:22 <annegentle> I will blame my cats
20:20:40 <ttx> damn cats
20:21:05 <dhellmann> cats are definitely anti-democratic
20:21:05 <mordred> annegentle: I also blame your cats
20:21:13 <dims> talked to a few openstack-salt folks
20:21:15 <dims> #link https://review.openstack.org/#/c/377906/
20:21:19 * flaper87 blames all cats
20:21:28 <mtreinish> annegentle: heh, well it's one less yes than before so you're not alone :)
20:21:31 <annegentle> they are needy and all
20:21:32 <dims> looks like they are not sure what they want to to
20:21:36 <dims> to do
20:21:43 <ttx> 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 <ttx> then +1ed the removal from governance
20:22:05 <dims> several folks already chimed in on the review
20:22:06 <annegentle> dims nice work then
20:22:08 <annegentle> there
20:22:11 <anteaya> they somehow think they have to move to github
20:22:28 <dims> i have been guiding them that it's ok to leave repos here if they wish
20:22:30 <dhellmann> anteaya : I think that was cleared up in the last comment
20:22:40 <anteaya> dims: do they know that being removed from governance means they can continue to use all our services
20:22:41 <sdague> dims: looks like a plan.
20:22:51 <anteaya> dhellmann: okay
20:22:52 <dims> 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 <anteaya> dims: great thank you
20:23:26 <ttx> mordred: sounds like a good idea
20:23:30 <sdague> 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 <dims> mordred : +1 if you can catch some of the higher ups, that would help too i think
20:23:39 <dims> sdague : true
20:23:50 * thingee is back - bad lag
20:24:14 <dhellmann> sdague : add the feature to gerrit to make renaming a repo easier so we can use a separate namespace again?
20:24:16 <anteaya> well renaming the file to removed from goverance instead of retired should help a bit
20:24:16 <johnthetubaguy> sdague: that does seem to surprise everyone
20:24:21 <ttx> sdague: it's something we lost when we removed stackforge branding. "Unofficial" doesn't have the same effect
20:24:21 <dims> mordred : ttx : i think post-acquisition they are changing focus/strategy too
20:24:32 <annegentle> more docs? Not sure where though.
20:24:34 <ttx> dims: yes, I gathered that much from change of tone
20:24:37 <mordred> dims: yah, I could certainly see that
20:24:52 <flaper87> 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 <dims> i am sad, but can't help it
20:25:13 <anteaya> dims: you did a good job communicating
20:25:15 <anteaya> dims: thank you
20:25:33 <dims> thanks anteaya
20:25:43 <ttx> Looks like they should be removed while they reassess their situation
20:25:47 <fungi> 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 <dims> ttx : yes
20:25:53 <dims> #link https://review.openstack.org/#/c/377906/
20:25:58 <russellb> it's a huge issue, i hear it all the time
20:26:06 <dhellmann> oh, do we want this patch to be updated to move them to the retired file?
20:26:07 <mestery> russellb: ++
20:26:08 <russellb> it really confuses people trying to figure out what is openstack
20:26:29 <fungi> russellb: because they should be asking "who" rather than "what" maybe?
20:26:32 <flaper87> dhellmann: good catch, I think we do
20:26:35 <flaper87> dims: ^
20:26:50 <russellb> fungi: i don't thing consumers care about who all that much
20:26:51 <ttx> ah, yes
20:27:10 <dims> 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 <jbryce> 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 <russellb> i tend to agree with the argument that all of this primarily benefits the dev community, and not everyone else
20:27:33 <fungi> jbryce: sure, but we can explain that some questions are based on false assumptions
20:27:35 <ttx> dims: I'd rather move it to the retired file and then rename the file
20:27:35 <russellb> our job got easier, everyone else got more confused
20:27:40 <dims> damn the netsplit is killing me
20:27:41 <dhellmann> dims : if you want to just add it in a follow-up, we'll retain the existing votes from the team
20:27:44 <jbryce> russellb: +100
20:27:46 <dhellmann> dims : if you want to just add it in a follow-up, we'll retain the existing votes from the team
20:27:50 <dims> dhellmann : sounds good
20:27:53 <mestery> jbryce russellb: +1
20:27:57 <russellb> just some final ranting before i drop off the TC, i guess..
20:28:02 <ttx> ok, let's merge that one and then move
20:28:07 <ttx> russellb: ow no!
20:28:18 <ttx> OK approved
20:28:32 <ttx> dims: if you submit the other one we can quick-merge it
20:28:44 <ttx> Let's move on to next topic
20:28:49 <dims> ttx : ack after this meeting
20:28:53 <ttx> #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 <ttx> #link https://review.openstack.org/371777
20:29:10 <ttx> I think this one if a no-brainer, since it's more the result of code split than anything new.
20:29:23 <ttx> But yes, interesting precedent to set
20:29:23 <dhellmann> yeah, we should have done this when the new repo was added, really
20:29:24 <flaper87> markvoelker: thanks for clarifying things there
20:29:26 <russellb> yep
20:29:33 <markvoelker> flaper87: sure thing
20:29:34 <mtreinish> ttx: fwiw, I still think there is still some confusion around the purpose of that tag
20:29:41 <ttx> any last-minute comment before we approve ?
20:29:43 <dhellmann> we should look at glance_store, ironic-lib, etc. too
20:29:44 <mtreinish> I'm not sure how to clean it up though
20:30:02 <markvoelker> dhellmann: glance_store is actually being looked at right now as a matter of fact
20:30:07 <dhellmann> good
20:30:08 <sdague> mtreinish: https://review.openstack.org/#/c/374027/
20:30:11 <flaper87> markvoelker: great
20:30:16 <dhellmann> markvoelker : thanks for cleaning this up :-)
20:30:20 <flaper87> mtreinish: sdage has a patch that should help
20:30:22 <ttx> mtreinish: we should do a "5 top myths about the TC" lightning talk
20:30:29 <flaper87> ttx: lol
20:30:33 <fungi> sort of wondering if that interpretation also makes most of oslo tc-approved-release
20:30:44 <mtreinish> sdague: yep that would do it :)
20:31:04 <mtreinish> sdague: heh, although there might also be confusion about what defcore means, but that's something else
20:31:05 <smcginnis> ttx: That's actually not a bad idea. ;)
20:31:23 <ttx> ok, approving now based on existing votes
20:31:33 <sdague> 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 <flaper87> ttx: go go go
20:31:39 <ttx> but yes, that raises questions for Oslo, ironic-lib or glance_store
20:31:39 <mtreinish> ttx: heh, 1 myth per minute :)
20:32:13 <fungi> 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 <ttx> OK, next topic...
20:32:36 <ttx> #topic Write down OpenStack principles
20:32:36 <sdague> 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 <ttx> #link https://review.openstack.org/357260
20:32:50 <dhellmann> 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 <dhellmann> which makes it less likely that oslo is a good candidate to be added
20:32:58 <ttx> 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 <ttx> rather than wait forever for an hypothetical perfect version
20:33:17 <flaper87> can we have stars/favs/hearts on gerrit ? #halfjoke
20:33:21 <ttx> 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 <ttx> The change has majority support now, so I'll approve it unless someone objects
20:33:35 * flaper87 agrees
20:33:50 <edleafe> "Perfection is the enemy of the good"
20:33:56 <flaper87> no objections here. I'd love to see some of these principles to be improved individually
20:34:01 <mordred> flaper87: ++
20:34:05 <ttx> well, I'm a perfectionist, but also a pragmatist
20:34:12 <dims> flaper87 : agree
20:34:51 * flaper87 will rebase his "good fatih" patch as soon as this one lands
20:34:58 <ttx> Thanks to mordred for writing the initial version, even if I ended up watering it down quite a bit
20:35:03 <flaper87> we can have that convo later too
20:35:13 <flaper87> thanks mordred and thanks ttx for addressing comments
20:35:32 <ttx> alright, it's in
20:35:35 <mordred> 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 <anteaya> ttx: thank you for all your hard work on this
20:36:01 <thingee> ++
20:36:03 <dhellmann> ++
20:36:05 <johnthetubaguy> ++
20:36:07 <jroll> +1
20:36:10 <dims> thanks ttx
20:36:24 * flaper87 proposes a group hug
20:36:28 <ttx> Thanks for the support everyone!
20:36:45 <ttx> and... moving on before flaper87 reaches me
20:36:45 * dhellmann links arms with flaper87
20:36:53 <ttx> #topic Create a project tag for zero-downtime upgrades
20:37:04 <ttx> #link https://review.openstack.org/372686
20:37:08 <ttx> dolphm: around ?
20:37:13 <russellb> similar to other upgrade tags, this stuff is likely backend dependent, and we don't have good ways of capturing that
20:37:29 <russellb> i don't have a solution necessarily, but just a note
20:37:40 <ttx> I think it's a great idea to raise the bar here... which projects would be expected to pass that ?
20:37:50 <johnthetubaguy> so its mostly API based projects
20:38:02 <johnthetubaguy> I know OSIC is trying to help with getting more projects to zero downtime
20:38:03 <jroll> I believe dolphm is mostly out today, not sure if he'll make it here
20:38:07 <johnthetubaguy> I think keystone is almost there
20:38:09 <ttx> 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 <dhellmann> I was curious about which projects would have this, too
20:38:26 <ttx> I suspect keystone would work on it
20:38:33 <dhellmann> the test job implementation will be interesting
20:38:33 <flaper87> Glance likely
20:38:42 <sdague> yeh, my biggest concern is that we have some reasonable validation here before we assert anything
20:38:49 <johnthetubaguy> I think the current work is around testing old and new APIs at the same time
20:38:49 <devananda> ironic is working towards it as well
20:39:01 <johnthetubaguy> sdague: thats a fair point, we are premature on that front
20:39:02 <flaper87> yeah, moving this forward without a good way to validate it won't add much value
20:39:05 <ttx> sdague: beyond validation, I'm concerned about regressing once you have it
20:39:09 <SpamapS> I think you can build on grenade for the testing.
20:39:18 <notmyname> swift would pass, depending on the "control plane" wording
20:39:18 <sdague> ttx: meaning?
20:39:19 <SpamapS> just have to make it multinode
20:39:25 <flaper87> ttx: I meant validation as a way to avoid regression
20:39:33 <mtreinish> SpamapS: we run grenade multinode already
20:39:34 <SpamapS> and upgrade one node, test, upgrade the other, test.
20:39:34 <flaper87> test it and watch for failures
20:39:36 <johnthetubaguy> right, I know we are thinking about grenade testing old and new API nodes living side be side
20:39:51 <jroll> devananda: ironic is working toward rolling upgrades, not zero-downtime, but that will be close and next :)
20:39:55 <johnthetubaguy> at least thats where I was thinking we would be going to validate zero downtime, in some sense
20:39:56 <jroll> just to be clear
20:40:08 <ttx> 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 <mtreinish> SpamapS: wouldn't that be rolling upgrade, not zero downtime?
20:40:25 <sdague> ttx: oh, sorry, when I mean validation I mean something that's running all the time validating
20:40:28 <sdague> agreed
20:40:32 <ttx> So I fear that the tag is the easiest part of this :)
20:40:32 <dhellmann> yeah, I'd like to see a requirement that the job already exist before the tag is added
20:40:37 <johnthetubaguy> ttx: honestly, we should test this in gate, to some extent
20:40:41 <fungi> jroll: how would you characterize rolling upgrades, if not some of your ironic nodes are upgraded and others aren't?
20:40:45 <SpamapS> mtreinish: Yes, but rolling is a precursor to 0-dt isn't it?
20:40:50 <ttx> johnthetubaguy: we are in violent agreement
20:40:50 <sdague> ttx: right, the tag seems premature in that regard
20:40:57 <devananda> jroll: right - our path to no-downtime starts with rolling. but that's the goal AIUI.
20:41:06 <johnthetubaguy> SpamapS: not always, depends on your architecture really
20:41:08 <ttx> sdague: maybe they want to use the tag as the carrot to motivate people to work on that ?
20:41:24 <sdague> lets get a CI model for testing this, especially as the techniques currently being proposed are database triggers
20:41:25 <flaper87> ttx: johnthetubaguy violence is not good :D
20:41:43 <sdague> which put logic in a place we don't really have test coverage
20:41:49 <ttx> but all that said, I think it's a nice target to shoot at
20:41:54 <flaper87> agreed
20:42:01 <johnthetubaguy> so part of this is making clear rolling upgrades includes API downtime
20:42:11 <johnthetubaguy> that was causing some confusion in internal discussions
20:42:16 <SpamapS> I guess I never really considered a scenario where rolling upgrades with downtime is a desired outcome of development.
20:42:29 <fungi> johnthetubaguy: thanks, that's what i was missing i think
20:42:50 <ttx> Yeah, I'll admit I missed that part too (API downtime in rolling upgrades)
20:42:55 <johnthetubaguy> SpamapS: short downtime is a heaps better than massive long downtime, thats where we were coming form before I believe
20:42:55 <SpamapS> But yeah, in that case, one needs to have a monitoring system get involved to verify uptime.
20:43:03 <SpamapS> johnthetubaguy: ack, just hadn't considered it.
20:43:29 <SpamapS> Is there a team that is chiefly responsible for writing and maintaining tests that validate tags?
20:43:31 <fungi> monitoring systems based on polling won't tell you that with any reliability
20:43:31 <johnthetubaguy> so I think the gate verification could just be mixed API nodes working together, thats the bit that would break
20:43:37 <ttx> OK, so... do we want to wait until we have some plan around testing before we approve this tag ?
20:43:38 <sdague> and, realize, there is still individual service server downtime in this model
20:43:44 <johnthetubaguy> ttx: that seems a good summary
20:43:48 <SpamapS> like, does QA take up that charge or does the TC just evaluate per-project?
20:43:51 <dhellmann> ttx: yes, let's wait for a more detailed plan
20:43:55 <sdague> but it depends on the idea of having multiple API servers in a load balancer
20:43:57 <thingee> ++
20:43:57 <flaper87> ttx: yup
20:43:58 * SpamapS apologizes for being a little uneducated on the tags system
20:44:09 <dhellmann> SpamapS : good question
20:44:16 <ttx> #info That's a great idea, but we need to nail down testing before we approve the tag
20:44:20 <russellb> each tag has a section that describes how it's applied
20:44:25 <russellb> and who is responsible
20:44:31 <sdague> so you are really running mixed API server versions in a load balancer against the same database
20:44:31 <russellb> or is supposed to..
20:44:33 <fungi> 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 <johnthetubaguy> 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 <dhellmann> fungi : right, I interpreted SpamapS' question as how do we know that has been done correctly?
20:45:18 <johnthetubaguy> 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 <sdague> johnthetubaguy: yeh, that should probably in there, that also informs the model for testing
20:45:23 <fungi> dhellmann: oh, thanks
20:45:31 <SpamapS> 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 <johnthetubaguy> sdague: yeah
20:45:40 <fungi> right, whether that's add haproxy in devstack multi-node or what
20:45:41 <flaper87> SpamapS: dhellmann I think we've done it by linking infra/gate reviews so far
20:45:49 <flaper87> and by manually checking tests are in place
20:45:57 <dhellmann> flaper87 : that works
20:46:10 <sdague> 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 <SpamapS> Sounds like the answer is that the TC does participate actively in the validation initially.
20:46:20 <johnthetubaguy> sdague: +100
20:46:57 <johnthetubaguy> I am not sure ha proxy is "good enough yet", I should really look into that
20:46:57 <flaper87> SpamapS: yeah
20:46:58 <ttx> ok, so we seem to have a way forward there
20:47:02 <mtreinish> sdague: yeah, that makes sense
20:47:22 <flaper87> SpamapS: but no actual tests are run manually. Just validate the tests are in place, running, voting, etc
20:47:29 <SpamapS> It would be great if we provided tools to each team to plug their testing/monitoring in so that we don't get 12 implementations though.
20:47:42 <sdague> ttx: well, we have an ask right. Please describe the test plan for this for services.
20:47:47 <sdague> before we move forward
20:47:48 <ttx> yep
20:47:50 <sdague> SpamapS: sure
20:47:50 <SpamapS> Or at least, help the teams collaborate.
20:47:51 <jroll|dupe> fungi: sorry, freenode being freenode, I think john answered your question
20:48:01 <fungi> jroll|dupe: indeed, thanks
20:48:04 <ttx> I'm moving on to open discussion, we can continue talking about this one
20:48:09 <ttx> #topic Open discussion
20:48:13 <sdague> yeh, it should be similar between services
20:48:19 <flaper87> jroll|dupe: I like jroll better. No ofense, though.
20:48:22 <ttx> #info A few days left to propose cross-project sessions
20:48:32 <ttx> #info Reminder: cross-project workshop submissions open @ https://etherpad.openstack.org/p/ocata-cross-project-sessions
20:48:40 <ttx> We'll look into them at next week meeting
20:48:50 <johnthetubaguy> sdague: I was thinking we could use grenade and run api on old and new side, like nova-compute, and add an old region into the keystone catalog, or something like that
20:49:04 <johnthetubaguy> ttx: I should send a poke email on the ML about that
20:49:07 <flaper87> happy to help with the scheduling job
20:49:07 <mtreinish> ttx: wouldn't that second one be a #link :)
20:49:10 <sdague> johnthetubaguy: we could... but multinode is hard for local reproduce today
20:49:11 <SpamapS> There are only really a few basic ways one validates uptime of anything. "Is it responding within latency thresholds? Is it spewing errors?"
20:49:16 <jroll|dupe> flaper87: freenode disagrees I guess :)
20:49:17 <ttx> johnthetubaguy: I did send a reminder already
20:49:20 <johnthetubaguy> sdague: oh good point
20:49:23 <ttx> (as a reply to your post)
20:49:31 <annegentle> #link  https://etherpad.openstack.org/p/ocata-cross-project-sessions
20:49:33 <johnthetubaguy> ttx: ah, I totally missed that
20:49:35 <flaper87> jroll|dupe: what does freenode know anyway? It can even keep 1 connection up
20:49:36 <sdague> johnthetubaguy: it would be good to figure out a model that makes it easy for projects to work on the problem in single node envs
20:49:47 <SpamapS> heh
20:49:50 <johnthetubaguy> sdague: yeah, good point
20:49:52 <SpamapS> this isn't a single node problem. :-/
20:49:57 <sdague> SpamapS: it can be
20:50:01 <johnthetubaguy> sdague: most folks don't need the multiple as such
20:50:06 <fungi> SpamapS: also your polling frequency needs to be an order of magnitude finer than the outages you're hoping to catch
20:50:08 <ttx> #info Other reminder: TC nominations are open
20:50:10 <sdague> if you have 2 API servers on the same node with different code
20:50:16 <ttx> with annegentle, dhellmann, mestery, mordred, russellb and sdague's seats up for renewal
20:50:26 <SpamapS> fungi: Yeah, that's where log error spew checking helps
20:50:35 <annegentle> I want to let you all know I'm not planning to run and encourage diverse candidates!
20:50:35 <johnthetubaguy> sdague: sounds like that venv discussion
20:50:36 <SpamapS> sdague: yeah, we could go with the port approach.
20:50:41 <SpamapS> or containers
20:50:57 <anteaya> annegentle: you are a diverse candidate
20:50:58 <ttx> #info Joint Board/TC/UC meeting on Monday, Oct 24 afternoon in Barcelona
20:50:59 <dims> SpamapS opens a can of worms :)
20:51:15 <sdague> SpamapS: yeh, venv + ports with a proxy. At least for the keystone case, I could see how that all works.
20:51:16 <flaper87> dims: lol, took the words right out of my mouth
20:51:17 <jroll|dupe> annegentle: I'll miss you being part of the TC <3
20:51:17 <anteaya> annegentle: would be a shame to lose you
20:51:23 <SpamapS> anyway, we fell into the implementation trap. The point is, there should be a harness or two that comes out of the first few of these, and it would be good to socialize the existence and methods
20:51:29 <flaper87> annegentle: :(
20:51:42 <dhellmann> SpamapS : ++
20:51:49 <dhellmann> annegentle :(
20:51:50 <SpamapS> sdague: cinder might suffer a bit
20:51:54 <flaper87> annegentle: fwiw, you did an amazing job and I thank you for all the time you spent as part of the TC
20:52:01 <sdague> annegentle: thank you for your service
20:52:07 <flaper87> annegentle: thanks for your dedication and passion
20:52:09 <devananda> annegentle: thank you for all your work on the TC - it was (and has continued to be) a pleasure to work with you.
20:52:11 <johnthetubaguy> annegentle :( sorry to see you go
20:52:29 <dhellmann> russellb : same for you, thanks for the time and energy you've given
20:52:30 <edleafe> annegentle: aw, it's always good to have your comments
20:52:33 <fungi> annegentle: i hope you run for the board next ;)
20:52:36 <dims> annegentle : thanks for all your work and help and guidance
20:52:45 <edleafe> fungi: yes!
20:52:46 <dims> fungi : ++
20:52:50 <annegentle> thanks all :)
20:52:56 <russellb> yeah, i'm out too
20:53:00 <russellb> so long, and thanks for all the fish
20:53:11 <annegentle> russellb well done sir
20:53:12 <flaper87> russellb: indeed, thank you for all the time you've spent here. Many years of passion and sweat.
20:53:19 <sdague> russellb: thanks for your service as well
20:53:46 <ttx> russellb, annegentle: you'll both be very missed
20:53:46 <edleafe> yes, thanks for your contributions, russellb!
20:54:13 * mestery is also out as well
20:54:14 * mordred hands russellb and annegentle a lightly used cake he found as a way to say thanks
20:54:20 <mestery> It's been fun folks
20:54:21 <fungi> russellb: we can draft you back into the vmt!
20:54:21 <devananda> russellb: !! ... thank you for, well, all the countless things you have done in your time on the TC
20:54:28 * mordred hands some of the cake to mestery too
20:54:29 <dhellmann> mestery : you, too?!
20:54:30 <russellb> mestery: annegentle thanks for all you've done
20:54:33 <dhellmann> lots of turnover this time
20:54:38 <mestery> <3
20:54:46 <sdague> mestery: thanks you as well
20:54:47 <dims> thanks russellb !
20:54:51 <edleafe> mestery: you'll be missed
20:54:55 <flaper87> mestery: holy moly
20:55:05 <flaper87> mestery: thanks for your service
20:55:11 <devananda> mestery: ? ... thank you, too.
20:55:14 <dims> thanks mestery !
20:55:24 * flaper87 proposes another group hug and grabs ttx before he runs away
20:55:33 <dhellmann> mestery : thanks, it has been a pleasure serving with you
20:55:34 <ttx> ok ok group hug
20:55:37 <david-lyle> thanks russellb, annegentle and mestery
20:55:42 * dtroyer_zz trying to pick up the thread…
20:55:42 <flaper87> w00000000000h0000000000000000000
20:55:58 <ttx> mordred: you wanted to propose community through food ?
20:55:59 <dtroyer_zz> did I miss anyone else?  mestery, russellb and annegentle?
20:56:03 <mestery> Thanks all, it has been very fulfilling working with you all :)
20:56:04 <jroll> russellb: mestery: thank you as well for everything you've done
20:56:04 <johnthetubaguy> russellb: mestery: annegentle: don't be strangers, thanks for all your hard work!
20:56:19 <dtroyer_zz> thanks all three
20:56:24 <ttx> johnthetubaguy:  we are losing them all to the "management track" monster
20:56:36 <johnthetubaguy> ttx: even worse
20:56:45 <jroll> oh my
20:56:52 <mestery> lol
20:56:56 <mordred> yah - so - if we're losing russelb and annegentle and mestery ...
20:57:11 <russellb> drink?!
20:57:13 <mordred> that means we're going to have some fresh fish to get to know
20:57:14 <annegentle> ha
20:57:15 <mestery> drink!
20:57:26 * jroll passes drinks around
20:57:33 <mordred> should we organize a TC (and outgoing TC) gathering in Barca?
20:57:38 <dhellmann> mordred : ++
20:57:38 * edleafe takes one
20:57:39 <SpamapS> we're all Salmon.. swimming upstream
20:57:41 * mordred would be happy to arrange
20:57:41 <flaper87> mordred: ++
20:57:56 <mordred> kk. I'll work on putting together an idea of something
20:57:57 <ttx> wouldn't hurt to get to know better the newcomers
20:57:58 <flaper87> SpamapS: oh, that explains many things
20:57:59 <jroll> mordred: ++
20:58:44 <dims> ttx ++
20:58:51 <ttx> mordred: I'll take my crystal ball and try to predict a good day for that
20:59:20 <ttx> mordred: apparently the Monday night there is a 7:30-9:00pm Joint BoD / TC / UC / OS Staff Dinner
20:59:25 <johnthetubaguy> right after the join board TC meeting?
20:59:28 <johnthetubaguy> oh
20:59:31 <ttx> at a "Nearby Walkable Restaurant"
20:59:44 <dhellmann> ttx: is there going to be some sort of invitation/announcement/head count for that?
20:59:48 <russellb> are there offiicial conf parties?
20:59:56 <russellb> or are the rest of the nights fair game?
20:59:57 <fungi> staff too? maybe i'll be there then
21:00:06 <Rocky_g> ++  Thanks annegentle russellb mestery for all your hard work her and other placees in OpenStack.  Still look forward to seing you in the other places
21:00:09 <mordred> russellb: I don't think I've gotten any invites to any :)
21:00:13 <ttx> dhellmann: I guess there will be, I just happened to read it on some unofficial schedule
21:00:15 * flaper87 neither
21:00:24 <russellb> mordred: same here, but another party organizer was asking me
21:00:30 * ttx will try to make sense of the party days and confer with mordred
21:00:37 <dims> ah i went hunting in my email folders
21:00:38 <ttx> and that closes our meeting
21:00:44 <flaper87> o/
21:00:48 <flaper87> bye everyone
21:00:54 <flaper87> thanks again russellb annegentle and mestery
21:00:55 <ttx> #endmeeting