18:00:16 <lbragstad> #startmeeting keystone
18:00:17 <openstack> Meeting started Tue Aug 22 18:00:16 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:18 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, notmorgan, rderose, rodrigods, samueldmq, spilla, aselius, dpar
18:00:20 <openstack> The meeting name has been set to 'keystone'
18:00:23 <spilla> o/
18:00:23 <samueldmq> hi
18:00:24 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:25 <samueldmq> o/
18:00:26 <lbragstad> agenda ^
18:00:29 <lbragstad> o/
18:00:32 <gagehugo> o/
18:00:37 <knikolla> o/
18:00:55 <cmurphy> o/
18:01:13 <raildo> o/
18:01:29 <rodrigods> o/
18:01:45 <lbragstad> ok - let's get started
18:01:48 <lbragstad> #topic announcements
18:01:52 <lbragstad> kinda of a fire going on today
18:02:14 <lbragstad> i was going through our release notes for pike today and notices a bunch of old release notes were rendering
18:02:23 <lbragstad> #link https://docs.openstack.org/releasenotes/keystone/pike.html
18:02:32 <lbragstad> stuff that was fixed in ocata or newton
18:02:49 <lbragstad> turns out release notes are generated based on when they are touched
18:02:49 <kmalloc> lbragstad: +2/a on the last one
18:03:10 <lbragstad> and we had a change come through to update a bunch of the release notes to point to the right documentation after the great docs migration
18:03:13 <lbragstad> kmalloc: thnaks
18:03:34 <lbragstad> so - after talking to the release team - we have a couple action itmes
18:03:38 <samueldmq> lbragstad: aha, it'd useful to have a release: pike thing in the rns
18:03:58 <lbragstad> which will result in us having to cut an rc3
18:04:13 <lbragstad> 1.) we need to backport all doc patches to release notes to affected branches
18:04:36 <lbragstad> those patches can be found here
18:04:41 <lbragstad> #link https://review.openstack.org/#/q/topic:bug/1710572
18:05:03 <lbragstad> 2.) update any false positives in the current release notes
18:05:15 <lbragstad> so - stuff like this
18:05:17 <lbragstad> #link https://review.openstack.org/#/c/496322/
18:05:28 <lbragstad> gagehugo: has a patch on the way to fix another one
18:05:41 <lbragstad> #link https://review.openstack.org/#/c/496342/
18:05:46 <lbragstad> actually - it's right there ^
18:06:17 <lbragstad> in addition to that - reno provides a way to blacklist specific release notes from rendering for a release
18:06:35 <lbragstad> very similar to what horizon did here - https://github.com/openstack/horizon/commit/85fe8f3b5fdf526302831107aee0c372ac5a9fec
18:06:52 <lbragstad> I have a patch up that addresses this for pike
18:06:58 <edmondsw> o/
18:07:07 <lbragstad> #link https://review.openstack.org/#/c/496343/
18:07:44 <lbragstad> looks like everything is approved - so i'll monitor the gate until they merge
18:07:59 <samueldmq> ++
18:08:00 <lbragstad> if anyone notices something wrong in our release notes between now and then, please let me know
18:08:16 <edmondsw> good catch
18:08:19 <lbragstad> we might also need patches similar to https://review.openstack.org/#/c/496343/ for stable/ocata
18:08:53 <lbragstad> maybe just double checking that https://docs.openstack.org/releasenotes/keystone/ocata.html is accurate
18:09:08 <kmalloc> solution: never touch/fix a release note from previous releases
18:09:13 <kmalloc> (going forward)
18:09:34 <lbragstad> kmalloc: yeah - this totally slipped the radar
18:09:34 <kmalloc> we can't always keep links in shape, and knowing the limitation, we do our best but roll with it knowing 1yr out the docs don't matter
18:09:54 <kmalloc> so, policy: don't "update" reno once a release is cut.
18:10:09 <kmalloc> following this round of "whelp, we're there" or we revert the changes
18:10:14 <kmalloc> from this round
18:10:19 <kmalloc> which is also valid
18:10:51 <lbragstad> however we decide to handle it - we should document the process in out release notes docs
18:10:59 * kmalloc votes for revert.
18:11:08 <kmalloc> and document no change-y going forward
18:11:10 <lbragstad> #link https://docs.openstack.org/keystone/latest/contributor/release-notes.html
18:11:56 <kmalloc> especially for ocata/newton
18:12:06 <kmalloc> pike... less of a concern since we're cutting rc3 anyway
18:12:50 <samueldmq> lbragstad: yes we definitely need to update that doc
18:13:05 <kmalloc> tl;dr lets halt the patches for Ocata/Newton and just revert
18:13:15 <lbragstad> i noticed a couple other nits when parsing the release notes that i'll include in an update
18:13:17 <kmalloc> and with pike *either* revert or roll forward but policy fixed.
18:13:24 <samueldmq> kmalloc: the patches that touched the rns?
18:13:38 <samueldmq> do they just make some corrections to the rns or something else?
18:13:58 <lbragstad> we also have to think about the backport process
18:14:08 <lbragstad> if a fix needs to go to stable/pike and it has a release note
18:14:49 <samueldmq> lbragstad: yeah, how is that included in the stable branch's RNs?
18:14:58 <samueldmq> since it's based on dates?
18:15:03 <kmalloc> lbragstad: i just switched the stable branch fixes for the links to a -2
18:15:04 <kmalloc> ftr
18:15:18 <lbragstad> kmalloc: except for stable/pike, right?
18:15:21 <kmalloc> lbragstad: backport the release note.
18:15:35 <kmalloc> yeah stable pike is still +2/+A, but i would vote a revert over rolling forward
18:15:43 <lbragstad> samueldmq: release notes from stable are rendered from the stable/branch
18:15:52 <kmalloc> you can backport a clean reno to stable as it will be redered sanely
18:15:59 <kmalloc> just don't ever "update" a reno that has been released
18:16:10 <kmalloc> basically don't change release notes once merged
18:16:25 <samueldmq> lbragstad: I was wondering specifically the new RNs we backport
18:16:27 <kmalloc> if it hasn't been merged to a stable/* branch, it is fine to do so.
18:16:32 <kmalloc> it will render sanely
18:16:35 <samueldmq> if they get included in stable/*
18:16:35 <kmalloc> on the next stable release
18:16:49 <knikolla> kmalloc: this one's for pike https://review.openstack.org/#/c/496323/
18:16:49 <lbragstad> that seems somewhat counter-intuitive to keep the release note in source control... but i don't have much of an alternative
18:17:05 <dhellmann> kmalloc : no, don't change release notes anywhere other than the branch on which they apply.
18:17:14 <dhellmann> kmalloc : changing it on the same branch works fine.
18:17:27 <kmalloc> dhellmann: except if the reno was originally in say ocata
18:17:30 <kmalloc> don't change it in pike
18:17:35 <kmalloc> it will then render as a pike change in docs
18:17:36 <dhellmann> kmalloc : right, change it in stable/ocata
18:17:39 <kmalloc> w/o a lot of extra work
18:17:39 <samueldmq> dhellmann: aha, makes sense.
18:17:42 <samueldmq> change in stable/ocata
18:17:48 <samueldmq> and leave it "unfixed" in master
18:17:50 <dhellmann> change the note in the branch where the note applies
18:17:51 <dhellmann> right
18:18:01 <kmalloc> "fixing links" is counter-intuative though
18:18:15 <kmalloc> i'd vote don't bother fixing on stable/ocata unless the reno is really b0rked
18:18:16 <lbragstad> i wonder if sorting release notes by dir would be more helpful?
18:18:27 <dhellmann> the real right way to fix those links would have been to set up redirects for them, rather than editing the old content
18:18:28 <kmalloc> not for things like updated links
18:18:41 <lbragstad> dhellmann: well - the redirects were in place
18:18:42 <kmalloc> dhellmann: welcome to bad doc migration with no redirects
18:18:51 <kmalloc> dhellmann: or so i understand
18:19:02 <dhellmann> you have in-tree redirects set up?
18:19:04 <kmalloc> lbragstad: ok so revert pike changes plz
18:19:07 <kmalloc> instead
18:19:24 <kmalloc> dhellmann: no for things like o.o/developer -> o.o./keystone
18:19:32 <kmalloc> it wasn't docs in our tree
18:19:33 <lbragstad> dhellmann: https://github.com/openstack/keystone/commit/77500b3615ae94ea45837f3fc0d503c8aadcc462
18:19:35 <kmalloc> it was external links
18:19:48 <dhellmann> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html
18:19:59 <lbragstad> it was stuff like https://docs.openstack.org/developer/devstack/plugins.html -> https://docs.openstack.org/devstack/latest/plugins.html
18:20:19 <kmalloc> uh.
18:20:20 <kmalloc> yeah
18:20:21 <dhellmann> ok. that would have meant updating the docs in the devstack repo
18:20:25 <kmalloc> again not in our tree
18:20:31 <lbragstad> which does make sense because the old link drops you at the wrong spot with the redirect
18:20:32 <kmalloc> so, lbragstad revert pike
18:20:51 <lbragstad> kmalloc: well - my previous statment is true for some links in our tree too
18:20:59 <lbragstad> let me find another example that applies to keystone
18:21:19 <kmalloc> if it's 100% in our tree, what dhellmann pointed out for the .htaccess is fine, right?
18:21:28 <kmalloc> i was looking strictly at the external links
18:21:44 <dhellmann> yeah, if it's in a different repo the redirects need to be set up over there, but the process is the same
18:22:36 <lbragstad> so we need a redirect for https://docs.openstack.org/developer/keystone/event_notifications.html
18:22:42 <lbragstad> to https://docs.openstack.org/keystone/latest/advanced-topics/event_notifications.html
18:22:55 <kmalloc> lbragstad: ok i've swapped everything to -2 except the link for the pike-specific bug
18:23:09 <dhellmann> the global htaccess file would redirect https://docs.openstack.org/developer/keystone/event_notifications.html to https://docs.openstack.org/keystone/latest/event_notifications.html
18:23:20 <dhellmann> so you need in the keystone tree a redirect from that 2nd url to the real new location
18:23:43 <kmalloc> https://review.openstack.org/#/c/496322/1/releasenotes/notes/bug_1698900-f195125bf341d887.yaml is the only one not -2 now
18:23:55 <kmalloc> that one looks to be legitimately a pike thing
18:24:11 <lbragstad> kmalloc: and the patch gagehugo has up
18:24:27 <kmalloc> which is from gagehugo
18:24:30 <lbragstad> it was a by-hand revert that didn't catch the release note
18:24:47 <lbragstad> #link https://review.openstack.org/#/c/496342/
18:25:04 <kmalloc> ok cool that one is being left alone
18:25:22 <lbragstad> alright - so it looks like i need to investigate the .htaccess change
18:25:24 <kmalloc> though, if it was a revert of code...
18:25:26 <lbragstad> and get that done sometime today
18:25:32 <kmalloc> was the code across releases?
18:25:39 <lbragstad> kmalloc: no
18:25:40 <kmalloc> if so, don't remove the release note, add a new one
18:25:44 <kmalloc> saying the code was reverted
18:25:46 <kmalloc> ok
18:25:57 <lbragstad> ok - so to recap
18:26:10 <lbragstad> #info don't modify release notes across releases
18:26:24 <kmalloc> don't modify release notes once they are merged*
18:26:25 <lbragstad> #action propose an .htaccess file for keystone doc redirects
18:26:34 <kmalloc> really. just don't
18:26:42 <kmalloc> unless it is a within-release revert
18:26:53 <kmalloc> dhellmann: thanks for stepping in and helping
18:26:56 <gagehugo> ok
18:27:08 <lbragstad> #action update release notes to reflect the outcomes and reasoning discussed in this meeting
18:27:23 <lbragstad> and - we still need a new rc because of the following:
18:27:32 <samueldmq> dhellmann: thanks
18:28:06 <lbragstad> #link https://review.openstack.org/496342
18:28:59 <lbragstad> and we need to revert #link https://github.com/openstack/keystone/commit/77500b3615ae94ea45837f3fc0d503c8aadcc462
18:29:10 <lbragstad> in order to render release notes properly - right?
18:29:41 <lbragstad> or do we still need the patch that ignore specific release notes
18:29:55 <lbragstad> #link https://review.openstack.org/#/c/496343/
18:31:10 <samueldmq> fixing things for pike and reverting for other stable/ seems fine
18:31:40 <samueldmq> I'm fine either way. reverting things in pike would work too
18:31:48 <dhellmann> kmalloc, samueldmq: sure. let me know if you need help with reviews on those redirect patches
18:32:30 <kmalloc> samueldmq: revert anything that isn't explicitly a pike bug in the pike release
18:32:42 <kmalloc> i don't think anything landed, but if it did...
18:33:04 <lbragstad> dhellmann: on last quick question - if we revert https://github.com/openstack/keystone/commit/77500b3615ae94ea45837f3fc0d503c8aadcc462 do we still need the ignore-notes patch https://review.openstack.org/#/c/496343/?
18:33:29 <dhellmann> lbragstad : I think unfortunately you will, because the file will still be "touched" in the master branch
18:33:41 <lbragstad> dhellmann: ack - that's what i was curious about
18:33:41 <dhellmann> you might as well not revert, actually
18:33:58 <lbragstad> lol - since we're two steps away :)
18:34:05 <dhellmann> :-)
18:34:20 <lbragstad> kmalloc: ^
18:34:44 * kmalloc still is of the opinion revert.
18:34:56 <kmalloc> revert should not make the file touched
18:35:15 <kmalloc> unless reno is looking at git history
18:35:22 <lbragstad> well - regardless of what we do - we're still going to need https://review.openstack.org/#/c/496343/
18:35:28 <kmalloc> which case i have other complaints.
18:35:33 <lbragstad> with or without the htaccess file
18:35:39 <kmalloc> but that is not here or later.
18:35:44 <dhellmann> kmalloc : yes, reno looks at the git history. It reads content out of the git commits, not from the files in the working tree.
18:36:07 <kmalloc> can we just disable that and instead make it render based upon release note directory structure
18:36:12 <kmalloc> that feels like it's being too clever
18:36:22 <dhellmann> there isn't a "disable" -- that's just how it works
18:36:27 * lbragstad wondered that same thing a few months ago
18:36:43 * kmalloc wants reno to stop being used in keystone then. but that aside. *sigh*
18:36:47 <lbragstad> i think it was when stevemar was refactoring a bunch of the release notes for stable/newton
18:37:14 <dhellmann> refactoring?
18:37:22 <lbragstad> yeah - let me grab an example
18:37:30 <kmalloc> people not understanding (me included) reno.
18:37:40 <kmalloc> and making bad decisions based on lack of understanding
18:39:16 <knikolla> reno really wants release notes to be immutable
18:39:30 <dhellmann> no, making them mutable was one of the design requirements
18:39:41 <lbragstad> #link https://review.openstack.org/#/c/429179/
18:40:05 <lbragstad> #link https://review.openstack.org/#/c/429143/
18:40:11 <knikolla> i see. across deliverables at least.
18:40:11 <lbragstad> #link https://review.openstack.org/#/c/429145/
18:40:21 <lbragstad> #link https://review.openstack.org/#/c/429177/
18:40:42 <lbragstad> stevemar: had a bunch of patches proposed to the stable branchs to cleanup release notes after we started establishing conventions
18:40:49 <dhellmann> ah, yeah
18:40:54 <dhellmann> renaming should work, too
18:41:06 <dhellmann> with the same caveat: do it on the branch where the note appears
18:41:17 <dhellmann> *applies
18:42:28 <lbragstad> i want to say the majority if that was a change to master that was attempted to be backported?
18:42:38 <lbragstad> they were massive changes, and no one really understood them
18:42:50 <dhellmann> ah, yeah, so that would cause the same sort of issues
18:42:51 <lbragstad> or specifically - how reno would interpret them
18:44:00 <dhellmann> if you wanted to rename those, the way to do it would be to start with the oldest stable branch and rename the files there
18:44:10 <dhellmann> then forward port that patch to the next branch and rename any others
18:44:16 <dhellmann> lather, rinse, repeat
18:44:37 <dhellmann> hrm, no, not quite
18:44:42 <dhellmann> you wouldn't want to forward port
18:44:48 <lbragstad> i was gonna saw
18:44:50 <lbragstad> say*
18:44:56 <dhellmann> you'd want to rename the files in each branch that didn't exist in the older branches
18:45:04 <kmalloc> it feels like that is a case that reno doesn't handle well?
18:45:17 <dhellmann> yes, it was not designed for a wholesale renaming
18:45:21 <lbragstad> i started trying to think about how that would work and my ears started smoking
18:45:25 <dhellmann> it was designed to let you fix broken things
18:45:52 <dhellmann> but "I don't like the naming convention we used" wasn't really on the list of potential breaks :-)
18:45:52 <lbragstad> so - that's another point that once a release note merges - it shouldn't be updated
18:46:08 <lbragstad> dhellmann: sure - that was something we came up with later
18:46:18 <kmalloc> i like the policy of just not updating release notes in tree once it merges
18:46:22 <lbragstad> in the case - i'd be fine letting older branches bit rot
18:46:24 <dhellmann> you can safely make changes on the stable branch where the note applies, including editing the content, renaming the file, and even deleting the note
18:46:25 <kmalloc> as long as we're using reno in this case.
18:46:46 <dhellmann> but you should probably minimize the amount you do it
18:46:59 <dhellmann> consider the fact that the source distribution won't include the update
18:47:01 <kmalloc> fair, but it would be much easier to just let people know to not change things.
18:47:11 <kmalloc> less headaches
18:47:15 <dhellmann> well, that's up to the keystone team to set as a policy
18:47:17 <kmalloc> source distribution and otherwise
18:47:18 <lbragstad> so - if a patch merges in master (which is under pike development) we have up to the release of pike to make changes without messing this up
18:47:18 <kmalloc> yeah
18:47:22 <kmalloc> was speaking for us
18:47:27 <kmalloc> not openstack as a whole ;)
18:47:40 <dhellmann> lbragstad : and after the stable/pike branch is created, you can continue to update the file on that branch safely
18:47:49 <dhellmann> but yeah, if you want a simple rule, just don't change things :-)
18:47:54 <lbragstad> ok
18:47:56 <kmalloc> i like the simple rule
18:48:25 <lbragstad> man - thinking about writing patches to stable branches without backporting to master feels weird :)
18:48:39 <lbragstad> backporting from master*
18:49:06 <lbragstad> ok - so it sounds like we have to document this process
18:49:09 <lbragstad> i can do that
18:49:25 <lbragstad> then we're going to revert https://github.com/openstack/keystone/commit/77500b3615ae94ea45837f3fc0d503c8aadcc462
18:49:27 <lbragstad> right?
18:49:33 <dhellmann> lbragstad : https://review.openstack.org/#/c/496318/
18:49:51 <lbragstad> dhellmann: oh - nice
18:50:09 <lbragstad> kmalloc: and we'll still need https://review.openstack.org/#/c/496343/ based on how reno works, at least for this release because of the doc migration
18:50:18 <lbragstad> s/because of the doc migration//
18:51:09 <gagehugo> should I abandon https://review.openstack.org/#/c/496342/ then?
18:51:27 <lbragstad> well - that should still go into master i think
18:51:35 <lbragstad> because it was missed in a previous revert
18:51:54 <gagehugo> ok
18:52:13 <lbragstad> but we also need to remove it from stable/pike *or* ignore it
18:52:24 <lbragstad> since the release note is advertising false information
18:52:34 <lbragstad> (since the patch was reverted)
18:53:36 <kmalloc> delete sounds like it always works
18:55:40 <knikolla> lbragstad: should we exclude this specific file from the revert? it's not a release note https://review.openstack.org/#/c/496367/1/devstack/plugin.sh
18:55:56 <lbragstad> knikolla: yeah - let's update that separately though?
18:56:09 <knikolla> lbragstad: ok, ++
18:56:23 <lbragstad> #link https://review.openstack.org/#/c/496367/1 reverts the links
18:56:58 <lbragstad> does anyone have any questions?
18:57:07 <lbragstad> about the process or what we need to do for rc3?
18:57:18 <cmurphy> are there any patches that non-stable-cores can help with atm?
18:57:46 <lbragstad> we need to document things so we don't end up here again :)
18:58:28 <knikolla> lbragstad: this needs to go to master too right?
18:58:48 <lbragstad> knikolla: what needs to go to master?
18:58:56 <knikolla> errr.. copy pasta fail. https://review.openstack.org/#/c/496343/
18:59:18 <lbragstad> knikolla: according to dhellmann it should go directly to pike
18:59:33 <lbragstad> sorry for burning the whole hour here
19:00:11 <lbragstad> head to #openstack-keystone and we can continue there
19:00:14 <lbragstad> thanks all
19:00:16 <lbragstad> #endmeeting