16:01:01 <markvoelker> #startmeeting defcore
16:01:01 <openstack> Meeting started Wed May  4 16:01:01 2016 UTC and is due to finish in 60 minutes.  The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:04 <openstack> The meeting name has been set to 'defcore'
16:01:07 <markvoelker> #chair hogepodge
16:01:07 <openstack> Current chairs: hogepodge markvoelker
16:01:13 <markvoelker> o/
16:01:16 <hogepodge> o/
16:01:30 <markvoelker> #info Meeting Agenda: https://etherpad.openstack.org/p/DefCorePostAustin.1
16:01:30 <catherineD|2> o/
16:01:58 <markvoelker> Small crowd today...everyone still hung over from Austin? =p
16:02:16 <docaedo> o/
16:02:17 <catherineD|2> yea
16:02:27 <docaedo> I'm still so deeply buried :)
16:02:45 <markvoelker> #info Co-chair hiatuses (hiatusi?)
16:03:23 <markvoelker> FYI, Egle is going to be away for a couple of weeks while welcoming a new addition to her family.  I'll be away the next two weeks due to business travel.
16:03:35 <markvoelker> So, in the meantime, email is probably the best way to get a hold of us. =)
16:03:52 <hogepodge> I'll be running the meetings, but I imagine during that time we'll put major decisions on hold. :-D
16:03:53 <markvoelker> hogepodge has graciously volunteered to run the meeting next week and the week after.
16:04:26 <markvoelker> With that, let's dive into today's (probably short) agenda....
16:04:35 <markvoelker> #topic Cycle Naming
16:04:58 <markvoelker> In today's etherpad you'll find the list of candidate names we received at the Austin summit for the next DefCore cycle.
16:05:18 <markvoelker> As you're all aware, there are only two hard problems in computer science: cache invalidation, naming things, and off by one errors. =)
16:06:06 <markvoelker> The naming is fairly inconsequential to me personally, but I don't think we have enough quorum today for a vote, so I'll propose that I send out out Doodle poll today to the alias with voting to conclude Friday.
16:06:09 <markvoelker> Any objections?
16:06:32 <hogepodge> nope
16:07:05 <markvoelker> #action markvoelker to send out a doodle poll for naming the DefCore cycle, voting to conclude Friday
16:07:25 <markvoelker> OK, moving on...most of the rest of the agenda today is a quick rundown of AI's from Austin so folks know what they're working on
16:07:39 <hogepodge> add suggestions to the list now if there's a name you like better
16:07:39 <markvoelker> #topic Gate Fixes
16:08:09 <markvoelker> Several AI's here.  hogepodge, anything you want to say about the JSON schema patch?
16:08:25 <hogepodge> I've written a schema and have tox code in place to check it
16:09:10 <hogepodge> I need to refactor the tox a bit, and would like a sanity check of the schema. Once we merge it we can update the gate to make it non-voting, and once we're happy with that we can make it voting.
16:09:25 <catherineD|2> so we will stop usong the rst schema version ?
16:09:43 <hogepodge> I generated some of the schema, the rewrote it by hand.
16:10:08 <hogepodge> catherineD|2: yes? Should we bump the version to 1.5 to keep the historic, since there will be changes to the guidelines (minor for consistency)
16:10:25 <catherineD|2> I think so that would be better
16:10:56 <markvoelker> Right, generally the idea is we've had our schemas documented in the doc/source/schema folder for a while, but haven't been validating them at the gate
16:10:56 <hogepodge> ok, I'll send the updates today
16:11:03 <markvoelker> (and have missed several violations)
16:11:19 <markvoelker> So hopefully this should fix that.  Long overdue, IMHO, so thanks for working on it hogepodge. =)
16:11:35 <hogepodge> yup, and the new formal schema did a really good job of picking up minor violations
16:11:43 <hogepodge> it was fun
16:12:04 <catherineD|2> RefStack relies on the schema to render Guidlines
16:12:53 <markvoelker> catherineDl2: so hopefully this should prevent us from breaking you more often. =)
16:12:56 <catherineD|2> we will prepare to use the new json format schema .. I think it is better
16:13:24 <markvoelker> ++
16:13:31 <markvoelker> Ok, next item in this topic is doc generation.  hogepodge, that's you again.  Anything you need clarified?
16:13:41 <catherineD|2> hogepodge: give us a heads up before merging this patch ...
16:13:59 <hogepodge> nope, I just put it there to reinforce that it's on my agenda. I'll speak with the docs team about how to move forward.
16:14:18 <markvoelker> Just one note: our generated docs currently show all the process docs (2015A, B, 2016A).  I'm not sure that's useful.
16:14:31 <markvoelker> We should probably show the one that's actually being followed and not the others.
16:14:35 <hogepodge> +1
16:14:46 <catherineD|2> +1
16:14:47 <markvoelker> http://docs-draft.openstack.org/65/311265/3/check/gate-defcore-docs/9ee574a//doc/build/html/ < an example
16:15:14 <markvoelker> We might want to rework that page a bit to highlight Guidelines that are currently used for logo programs too I suppose
16:15:31 <hogepodge> +1
16:16:16 <markvoelker> Anyhow, we can take up stuff like that via gerrit, just a couple of things to think about. =)
16:16:48 <markvoelker> Ok, next item is mine: check next.json
16:17:47 <markvoelker> I'll have to go back to the Austin pad to clarify, but I think this one was to clean up some minor schema violations and make sure achievements are synced.
16:17:49 <hogepodge> markvoelker: this seems to overlap under the schema work I'm doing? That will add formal checks for next.json
16:18:00 <hogepodge> markvoelker: ah, I see
16:18:02 <markvoelker> hogepodge: exactly what I was going to say =)
16:18:14 <markvoelker> So, I'll leave the schema checks to your patch so we don't duplicate effort
16:18:39 <hogepodge> the script to check achievements will be important. I'm sure there's a lot of drift between scoring and guideline
16:18:57 <hogepodge> it would be nice if the guideline was the source of truth rather than the scoring document
16:19:07 <markvoelker> Quite possibly, yes.  I have an AI to work on the scoring script too a few bullets down, so I'll take this up there.
16:19:15 <hogepodge> (but I imagine the scoring document is the source of truth right now)
16:19:27 <VanL> Where is the scoring doc currently?
16:19:46 <markvoelker> VanL: https://github.com/openstack/defcore/blob/master/working_materials/scoring.txt
16:19:58 <VanL> markvoelker: Thnx
16:20:32 <markvoelker> VanL: you may recall that some folks asked for a spreadsheet-friendly version of that...the tabulate_scores.py script in the same directory will also generate a CSV for you if you like
16:21:08 <VanL> Ok. I remember when it moved off the googlesheet, but lost track after that.
16:21:19 <markvoelker> Ok,last item on this topic: hogepodge had an AI to clean out the guideline directories.
16:21:38 <markvoelker> hogepodge: any questions on that one?
16:22:59 * markvoelker hears none, so onward...
16:23:11 <markvoelker> #topic Testing fixes/additions
16:23:32 <catherineD|2> did we skip this topic Patch for Compute Flag Gap in 2015.07/
16:23:57 <markvoelker> catherineDl2: oops, yes...sorry, looking at wrong pad
16:24:11 <markvoelker> #topic Patch for Compute Flag Gap 2015.07
16:24:29 <catherineD|2> I happen to have question about this topic :-)
16:24:37 <markvoelker> catherineDl2: go for it
16:25:00 <catherineD|2> do we automatically carry the flag test over to the new Guideline?
16:25:13 <markvoelker> catherineDl2: generally, no.
16:25:34 <catherineD|2> do we have process for flag tests carry over ?
16:25:42 <markvoelker> The idea was generally that we'd review those flags with each new Guideline (usually a thing that whoever is playing point for that project works on)
16:25:54 <VanL> catherineD|2: To carry over the flag, or carry over the test?
16:26:09 <catherineD|2> carry over the flag
16:26:21 <markvoelker> And of course folks can always request flags once they run into problems during the vendor testing period that starts at each Summit (see timeline in etherpad)
16:26:48 * gema sits at the back of the room, quietly
16:27:10 <markvoelker> I'm expecting to see some incoming soon, personally (since I know we have some folks with testing in flight). =)
16:27:34 <markvoelker> catherineDl2: make sense?
16:27:37 <hogepodge> I'd like us to actively review flags and determine which need to be carried over, and which should be dropped.
16:27:40 <catherineD|2> markvoelker: yup thx
16:27:55 <catherineD|2> hogepodge: ++
16:27:58 <markvoelker> hogepodge: it does seem like an area we could tighten up process around
16:28:04 <hogepodge> but dropping all means none slip through the cracks, but it leads to inconsistencies like with have with 2015.07
16:28:08 <catherineD|2> hogepodge: I think so
16:28:38 <markvoelker> hogepodge: I had a request to write up a "how to" for scoring anyway...perhaps I should incorporate this into that and put up something for review?
16:28:54 <hogepodge> markvoelker: sure
16:29:16 <markvoelker> Ok, easy enough.
16:29:40 <catherineD|2> also with the new "test list" feature added to RefStack .. do we still need to keep the 201x.xx directoroes?
16:29:43 <markvoelker> #action markvoelker Write up flag inspection in forthcoming Scoring Guide
16:30:03 <catherineD|2> directories
16:30:09 <markvoelker> catherineDl2: hogepodge has an AI from above to remove them.=)
16:30:24 <catherineD|2> ok
16:31:01 <markvoelker> anything else on this topic?
16:31:21 <catherineD|2> nope
16:31:25 <markvoelker> #topic Regrouping an rescoring of Capabilities for 2016.08
16:31:46 <markvoelker> During discussion in Austin, we noted that the way we group Capabilities is a little inconsistent today
16:31:51 <markvoelker> (ok, a lot inconsistent)
16:32:17 <markvoelker> For example: in some cases we have CRUD operations as a single thing, other places not.
16:32:39 <markvoelker> It would be nice to clean those up and be more consistent.
16:32:46 <catherineD|2> I think we need to have a few working sessions for regrouping then rescoring
16:32:57 <markvoelker> catherineDl2: probably
16:33:23 <markvoelker> The general feeling in the room seemed to be (correct me if I'm mis-remembering) that generally grouping CRUD operations together was good
16:33:25 <catherineD|2> may need to set criteria for regrouping
16:33:39 <markvoelker> But there may be a few cases where it's not entirely feasible (those should generally be the exception though, not the rule)
16:33:59 <hogepodge> +1
16:34:25 <luzC> +1
16:34:28 <VanL> -1
16:34:46 <VanL> That was the problem that lead to the original splitting apart
16:35:06 <VanL> We had "Compute", with a bunch of random tests under it
16:35:27 <VanL> The issue was that this capability gave very little visibility into what that meant
16:36:03 <VanL> The entire genesis of the move from v1 of the json to v2 was to give more visibility into the capabilities
16:36:18 <markvoelker> VanL: right, in this case we're talking about CRUD on a single primitive.  So, for example: CRUD on routers is one capability.  CRUD on networks is one capability.  CRUD on subnets is one capability.
16:36:31 <VanL> We did that at first by just leveraging the names rather than looking at the tests
16:36:36 <markvoelker> Not: CRUD on all things compute-related is one capability.
16:37:04 <VanL> I still think that capabilities should continue to be fine-grained
16:37:41 <VanL> SHould there be cleanup on the tests? Sure, let's make sure the correspondence is there
16:38:13 <VanL> But we have been down this road, and it ended up being confusing
16:38:32 <gema> I think from the beginning that the capabilities should reflect API calls, not tests, but many operations are not CRUD
16:38:39 <markvoelker> VanL: it's a valid opinion. =)  The AI owners on this are hogepodge, dwalleck, and catherineDl2.  May I suggest that you work with them on an initial proposal and we'll take up the discussion in gerrit?
16:39:20 <VanL> Sure
16:39:37 <markvoelker> excellent
16:39:42 <hogepodge> So we have a choice of moving in two directions, more fine grained and more grouped. I propose that we send up a patch for both?
16:39:55 <markvoelker> Ok, anything further on this topic right now?
16:39:58 <hogepodge> It would be nice to see how they compare.
16:40:12 <VanL> hogepodge: The patches?
16:40:23 <markvoelker> hogepodge: sure, sounds reasonable.  I'll leave the mechanics to you guys.
16:40:31 <hogepodge> yes, to see the impact of grouping vs not grouping
16:40:35 <gema> VanL: I can help
16:40:48 <gema> VanL: I don't think grouping is the solution either
16:41:01 <VanL> gema: Great
16:41:55 <markvoelker> Cool, sounds like you guys have a path forward. =)  I'll look forward to seeing some patches to review.
16:42:10 <markvoelker> #topic Test Fixes
16:42:30 <markvoelker> In the last scoring cycle we identified a few things that needed tests written or tests refactored
16:42:40 <markvoelker> I think I have most of the AI's on this one right now...
16:43:02 <markvoelker> Neutron and Glance don't have tests for GET / (version discovery) which is a Capability we've included for Nova and KEystone
16:43:24 <markvoelker> I spoke with both of those groups about this at the Summit, and wrote up a quick POC for Neutron on the flight now
16:43:29 <markvoelker> s/now/home/
16:43:43 <markvoelker> It's winding it's way through review and needs additional work, but it's progress.
16:43:59 <markvoelker> Once that one settles out it should be trivial to do likewise for Glance
16:44:15 <markvoelker> We also identified some tests that use admin credentials
16:44:38 <markvoelker> Mostly these are for capabilities that are normally exposed to end users, so it's a test issue.
16:44:57 <markvoelker> I'm planning to work on the Neutron tests to see if we can refactor out the unnecessary admin credential usage
16:45:16 <hogepodge> I can take that AI, along with anyone else who might want to work on it.
16:45:31 <markvoelker> I think we still need someone to work on the volume-v2-transfer and volume-v2-qos tests though (if refactoring is possible there)
16:45:39 <hogepodge> Or, we can work on it together.
16:45:50 <markvoelker> hogepodge: sure, I won't say no to help. =)
16:45:54 <catherineD|2> so for the admin tests we do not want to remove or flag the tests until there are fixes ...  how do the users know that they fail these test because of admin credential .... just do not want to see them spend time in debugging things that we have identified.
16:46:11 <markvoelker> I think they have a common root problem though, so perhaps you want to attack the volumes stuff first?
16:46:18 <hogepodge> markvoelker: this is where launchpad (a later item in the agenda) can help. We can create tickets with the basic information to reference back to
16:46:35 <markvoelker> hogepodge: ++
16:46:44 <hogepodge> markvoelker: sure. If it's anything like the multi-tenant issue, it should be really easy to fix.
16:46:52 <markvoelker> catherineDl2: if there are admin tests in an existing Board-approved Guideline, I'm fine with flagging them
16:46:56 <hogepodge> probably a subclass with a different client
16:47:10 <markvoelker> In this case though, the Neutron tests at least are new entries for required status in next.json
16:47:25 <markvoelker> So I'ld like to try to get those tests refactored before this goes up the Board for approval
16:47:25 <catherineD|2> especially for the tests in https://review.openstack.org/#/c/299491/  .. .it took me a while to identify the failure causes
16:47:55 <catherineD|2> markvoelker: do we flag tests in the advisory section?
16:48:02 <catherineD|2> or just remove?
16:48:44 <markvoelker> catherineDl2: if we think they can be refactored, I'd just flag them.  If we remove them then they'll have to go through a whole new advisory cycle which seems unnecessary if it's just a test issue
16:48:49 <catherineD|2> those are the tests in the advisory section in  2016.01
16:48:54 <hogepodge> catherineD|2: I think it's situation dependent.
16:49:17 <markvoelker> And when flagging them I'd note the Launchpad bug ID that says we're working on the refactor =)
16:49:20 <catherineD|2> ok I will send a patch to flag them  in 2016.01
16:49:45 <markvoelker> hogepodge: right.  If we don't think the tests can reasonably be refactored, I'd be fine with dropping them.
16:50:40 <markvoelker> Ok, anything further here?
16:51:05 <markvoelker> #topic Proposed 2.0 schema
16:51:15 <markvoelker> #link https://review.openstack.org/#/c/310621/
16:51:57 <markvoelker> I'm not sure if there's much to say about this one right now other than "please review and discuss in gerrit".  Anyone have stuff to discuss about it here in the meeting?
16:52:06 * markvoelker is looking at the clock
16:52:54 <markvoelker> Ok then:
16:53:03 <markvoelker> #action everyone please review https://review.openstack.org/#/c/310621/
16:53:20 <markvoelker> #topic Fill Out Issues In Launchpad
16:53:46 <markvoelker> I took an AI to start working on adding stuff to LP, which I intend to start sifting through this afternoon.
16:53:47 <catherineD|2> Just one announcement ... RefStack IRC meeting is moving from Monday to Tuesday at the same time (19 UTC)
16:54:13 <markvoelker> I think the stuff we covered today is mostly a good start, but if I miss something then feel free to add it yourself
16:54:18 <markvoelker> (or bug me)
16:54:27 <markvoelker> catherineDl2: duly noted, thanks!
16:54:29 <hogepodge> (pun intended?)
16:54:38 <markvoelker> hogepodge: but of course =p
16:55:24 <markvoelker> I don't think I need any additional clarification on this AI, so move on?
16:56:02 <markvoelker> #topic Test Spec
16:56:32 <markvoelker> There was a bit of discussion in a couple of different sessions at the summit about some of what's in the etherpad for the test spec
16:56:50 <markvoelker> (I think some additional notes have been added)
16:57:28 <gema> shall we give it another week and then get a gerrit commit together?
16:57:35 <markvoelker> Generally, I think we came to the conclusion that we have enough to shift this over to gerrit and start +1/-1 discussion of it so we can bring up the individual points of debate more clearly
16:57:46 <gema> sounds good
16:57:56 <markvoelker> gema: I'll leave the timeline up to you...I'm fine with waiting a week if you think there's more stuff to land in the pad yet. =)
16:58:12 <gema> markvoelker: I may need a week to collect all the information and distill it
16:58:18 <markvoelker> gema: no problem
16:58:19 <gema> markvoelker: will get a commit in
16:58:32 <gema> hogepodge: make sure all your thoughts are in there somewhere
16:58:58 <hogepodge> +1
16:59:08 <markvoelker> Two minute warning...anything else on this?
16:59:26 <markvoelker> #topic Interop issues report
16:59:56 <markvoelker> Nothing much to say here other than: probably in the same boat.  REady to start moving to gerrit, and we have a little time so I'll probably concentrate on test-fixing and other AI's first
17:00:04 <markvoelker> Be sure to put your thoughts in the pad if you haven't already
17:00:10 <markvoelker> And we're out of time
17:00:21 <markvoelker> Thanks folks!  Over to #openstack-defcore
17:00:26 <markvoelker> #endmeeting