17:07:18 <aspiers> #startmeeting self-healing
17:07:19 <openstack> Meeting started Wed Dec  5 17:07:18 2018 UTC and is due to finish in 60 minutes.  The chair is aspiers. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:07:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:07:22 <openstack> The meeting name has been set to 'self_healing'
17:07:44 <aspiers> ekcs: did you see the minutes from earlier today? no worries if not
17:07:59 <ekcs> yup. I just read it.
17:08:06 <aspiers> cool
17:08:16 <aspiers> http://eavesdrop.openstack.org/meetings/self_healing/2018/self_healing.2018-12-05-09.33.html in case anyone else is wondering
17:08:38 <aspiers> #topic actions from meeting two weeks ago
17:08:56 <aspiers> I think I've either taken care of each action, or added it to storyboard
17:09:02 <aspiers> but let me know if I've missed anything
17:09:20 <ekcs> yup.
17:09:45 <aspiers> I also got a mail from (I guess) the same person who contacted Ifat earlier about the monasca/vitrage integration work
17:10:03 <aspiers> it was a very helpful and encouraging mail, so I'll respond soon
17:10:29 <aspiers> I only have a couple of things to discuss
17:10:32 <ekcs> that’s great!
17:10:44 <aspiers> #topic clarifying how to contribute to the SIG
17:10:50 <aspiers> https://review.openstack.org/#/c/620424/
17:11:04 <aspiers> did my review make sense?
17:11:53 <aspiers> e.g. the thing about how to handle implemented vs. not-yet-implemented use cases
17:12:04 <aspiers> I'm currently thinking an extra section in the template makes the most sense
17:14:06 <ekcs> yes thanks for the comments!
17:14:31 <ekcs> i’m not totally clear on the “status” idea.
17:14:52 <aspiers> so I think we definitely want to allow both use cases which are and aren't implemented
17:15:14 <aspiers> e.g. the memory leaks one suggested in Berlin has no "upstream" implementation yet
17:15:23 <aspiers> but describing the problem is a good first step towards that
17:16:10 <aspiers> the question is, how should we split those two categories up? into separate subdirectories is one possibility, but I think that's problematic
17:16:51 <aspiers> e.g. it would require moving the file when an implementation emerges, and the categories aren't really binary black-and-white anyway
17:17:44 <aspiers> so I'd prefer a "Current status" section in the template, which allows a freeform text description of the status
17:18:04 <ekcs> hmmm.
17:18:04 <aspiers> allowing things like "this bit is implemented, but this other bit isn't yet"
17:18:17 <aspiers> which can give more clarity
17:18:19 <ekcs> ah i see.
17:18:40 <ekcs> ok just to clarify, you mean this would be in categorizing use-cases
17:18:53 <ekcs> what about specs?
17:18:56 <aspiers> for use cases, yes
17:19:17 <aspiers> I think specs could be handled in the way they are handled in other repos
17:19:32 <ekcs> ok so specs are still separate.
17:19:35 <aspiers> yup
17:19:58 <aspiers> specs are for focusing on specific implementation details
17:20:07 <ekcs> so up till now use casse have been used for implemented cases.
17:20:15 <aspiers> yes, that would continue
17:20:27 <aspiers> specs are only for driving future dev work
17:20:33 <aspiers> sorry
17:20:47 <aspiers> maybe I wasn't clear here :)
17:20:58 <aspiers> let me rephrase
17:21:20 <aspiers> your point is that up till now, use-cases have *only* been used for implemented cases, and not for unimplemented?
17:21:39 <aspiers> I'm not sure that's true actually
17:21:57 <ekcs> ok.
17:22:00 <aspiers> https://docs.openstack.org/self-healing-sig/latest/use-cases/fenix-rolling-upgrade.html is arguably not yet implemented
17:22:03 <aspiers> at least not fully
17:22:23 <aspiers> which sort of demonstrates my point that "implemented vs. unimplemented" isn't a straightforward binary choice
17:22:31 <ekcs> so going forward we want use-cases to be used for use-cases at all stages of implementation. not started, in progress. completed. and everything in between.
17:22:37 <aspiers> exactly!
17:23:01 <aspiers> and a "Current status" section can give info on the status, or at least clues for where to look
17:23:11 <aspiers> e.g. it could just say "go check this storyboard story"
17:23:18 <ekcs> yea that makes sense.
17:23:19 <aspiers> that's up to the use case owner
17:23:26 <aspiers> OK great, let's take that approach then
17:23:55 <ekcs> still I think at some point we want to draw some kind of categorization.
17:24:11 <aspiers> #agreed Add a "Current status" section to use-cases/*.rst
17:24:38 <ekcs> for that someone who’s just looking to see how to use things won’t be confused or mislead by the unimplemented use cases.
17:24:44 <aspiers> We could separate them out in the index.rst, would that work?
17:25:01 <ekcs> it doesn’t have to be a separate dir but yes separate in index.rst can work
17:25:07 <aspiers> OK
17:25:37 <aspiers> I don't want to rule a separate dir out either
17:25:44 <aspiers> but I think for now we don't need it
17:25:50 <ekcs> ok not be belabor this too much.
17:25:54 <aspiers> right :)
17:25:59 <ekcs> but what’s the real disadvantage of separate dir?
17:26:13 <aspiers> mainly that it's not always clear which dir a use case should go in
17:26:24 <aspiers> e.g. the fenix one
17:26:44 <ekcs> it could help people who are just browsing git dir
17:26:50 <ekcs> ok
17:27:00 <ekcs> yea let’s just do with same dir then.
17:27:04 <aspiers> ok
17:27:18 <aspiers> #agreed stick with a single use-cases/ directory for now
17:27:31 <aspiers> #topic where to store high-level SIG info
17:27:40 <aspiers> so this is another thing which came up in that review
17:27:49 <aspiers> currently the SIG mission statement / scope are in the wiki
17:27:57 <aspiers> which is not subject to peer review
17:28:12 <aspiers> for that reason I think I'd prefer to move it to the git repo
17:28:30 <aspiers> e.g. I added a paragraph to the scope yesterday, but doing that didn't feel very democratic ;-)
17:29:15 <aspiers> do you think it's reasonable to move the more static info from the wiki into the git repo?
17:29:30 <aspiers> we could keep the more fluid sections in the wiki, e.g. upcoming and past events
17:29:49 <aspiers> but the rest could be moved to the docs and replaced with a link
17:30:26 <aspiers> maybe the project contacts could stay there too, I don't know
17:30:28 <ekcs> that makes sense. I agree that ultimately reviewed is better. at the same time, I feel it’s beneficial but not high priority at this point.
17:30:33 <aspiers> it probably doesn't matter too much
17:30:35 <aspiers> agreed
17:31:16 <aspiers> #agreed would be nice to move more static info about the SIG from the wiki to the git repo, but not high priority
17:31:34 <aspiers> #topic AOB
17:31:39 <aspiers> I think that's all I've got
17:31:42 <aspiers> anything from you?
17:31:59 <ekcs> no nothing more.
17:32:11 <aspiers> OK cool, thanks!
17:32:14 <aspiers> #endmeeting