16:00:57 <markvoelker> #startmeeting defcore
16:00:58 <openstack> Meeting started Wed Jun  1 16:00:57 2016 UTC and is due to finish in 60 minutes.  The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:01 <openstack> The meeting name has been set to 'defcore'
16:01:04 <markvoelker> #chair hogepodge
16:01:05 <openstack> Current chairs: hogepodge markvoelker
16:01:06 <Rockyg> o/
16:01:08 <markvoelker> o/
16:01:10 <shamail> Hi everyone
16:01:13 <hogepodge> o/
16:01:16 <catherineD> o/
16:01:27 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreLunar.5 Today's agenda
16:02:23 <markvoelker> Please jot any late-breaking additions to the agenda down on the etherpad
16:02:29 <markvoelker> With that, let's jump right in...
16:02:37 <markvoelker> #topic Test Spec Proposal (gema)
16:02:50 <markvoelker> #link https://review.openstack.org/#/c/317531/ Test spec proposal
16:03:14 <hogepodge> I think gema is on holiday
16:03:29 <markvoelker> hogepodge: yep, I think you're right.
16:03:34 <Rockyg> Yup.  Gives me another week to review;)
16:03:37 <hogepodge> (just remembered that)
16:03:53 <markvoelker> Some good discussion in the past couple of weeks, but this one could use some attention
16:04:02 * markvoelker wags finger at self
16:04:20 <markvoelker> Anything folks want to bring up for discussion on this one today?
16:04:23 <shamail> Same as Rockyg, another week would be great
16:05:07 <markvoelker> Ok, let's move on for now then.
16:05:13 <markvoelker> #topic TC DefCore Resolutions (passed May 31, 2016)
16:05:28 <markvoelker> #info The TC passed both DefCore-related resolutions before it this week
16:05:41 <markvoelker> #link http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20160504-defcore-proxy-tests.rst Resolution on proxy tests
16:05:57 <markvoelker> #link http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20160504-defcore-test-location.rst Resolution on test locations
16:06:15 <markvoelker> FYI, hogepodge already put up a patch in response to the proxy one
16:06:33 <markvoelker> #link https://review.openstack.org/#/c/323625/ Patch to remove proxy-related tests
16:07:24 <markvoelker> The proxy one is relatively straightforward I think.  For the other one, we should probably make sure projects that are impacted know about the change
16:07:30 <hogepodge> compute-images-create is an interesting one, because it's doing an image snapshot and leans upon glance for storage
16:07:58 <Rockyg> thanks, hogepodge
16:08:16 <hogepodge> this is why nova-glance v2 integration is still important to land upstream, so the mechanism isn't implicitly pulling in a deprecated api
16:10:16 <markvoelker> I don't think we actually currently have any tests in next.json that would fall afoul of the resolution saying that DefCore tests should live in Tempest, but I know the Heat and Swift folks had been planning to use in-tree tests.
16:10:25 <catherineD> markvoelker: For t he test location one, I wonder whether we should inform the Heat team about this.  Since we were advocate for them to implement the Tempest interface targeted for being inclusive for DefCore tests
16:11:32 <hogepodge> catherineD: Yes, they should be made aware of the resolution. As a working group, we still have the freedom to not recognize it, fwiw, if we really want tests outside of tempest for some reason
16:11:37 <Rockyg> The tc discussion also said they expected this might create duplicate (or close to dupe) tests in two places.
16:12:21 <markvoelker> catherineD: yeah, I was actually just looking over the review to see if anyone from heat-core commented.  I would hope the TC would make PTL's aware of decisions like this, but we can certainly inform them too
16:13:03 <shamail> We should add Cross Project Spec Liaisons to reviews that impact projects as a best practice
16:13:39 <catherineD> We were the one leading them to the Tempest plugin path for DefCore purpose at the time
16:13:41 <hogepodge> (as a side note to this meeting, VanL_ is either preparing to or currently delivering a pycon keynote, so I don't expect him to be here to comment directly on these agenda items)
16:14:19 <markvoelker> Ok, so how about I take an AI to send a note to openstack-dev with [heat] and [swift] in the headers about this?
16:14:31 <markvoelker> (if someone from the TC doesn't beat me to it =p)
16:14:34 <catherineD> markvoelker: that would be great.  Thanks!
16:14:51 <markvoelker> #action markvoelker Send email alerting devs to DefCore-related TC resolutions
16:15:12 <markvoelker> Ok, anything further on this?
16:15:17 <Rockyg> Cool.  Thanks
16:15:54 <Rockyg> This also broadcasts to dev that these projects are under consideration for inclusions
16:16:07 <shamail> Rockyg: +1
16:16:09 <Rockyg> although swift is already included...
16:16:51 <markvoelker> Ok, moving on...
16:16:53 <markvoelker> #topic Schema 1.5 for Gating
16:17:05 <catherineD> Heat is the target to score for inclusions but there are no meaningful tests (according to the heat team) in Tempest at the moment
16:17:28 <markvoelker> #link https://review.openstack.org/#/c/311265/ Added formal 1.5 json schema for gating against
16:17:53 <markvoelker> #link https://review.openstack.org/#/c/317800/ Add DefCore guideline gate checks for json lint and schema
16:17:57 <hogepodge> markvoelker: one thing that we lose in that schema are the definitions you linked to earlier on things like "required", "deprecated", etc
16:17:57 <Rockyg> From the app dev side, some are saying heat is the important "lowest level" for app devs to need to know.
16:18:13 <catherineD> RefStack site has been updated to handle 1.5 ...
16:19:00 <markvoelker> hogepodge: Yeah, I was actually just thinking about that before the meeting started today.  Feels like definitions that are unlikely to change should probably live in the lexicon
16:19:06 <markvoelker> What do you think?
16:19:49 <hogepodge> markvoelker: I think so too. I also strongly disagree with our definition of deprecated (it has meaning that is supposed to protect users), but that horse may be out of the barn
16:20:09 <Rockyg> Sounds good.  Don't want to lose the defs
16:21:03 <Rockyg> hogepodge, we can revisit any def with a patch and discussion....
16:21:33 <markvoelker> I think changing the definition is a conversation we can certainly have...there are pros and cons either way.
16:21:55 <hogepodge> markvoelker: +1
16:22:01 <hogepodge> Rockyg: +1
16:22:26 <markvoelker> Perhaps the best way to do this is to do two patches: one moving the definitions to the lexicon (which should be relatively uncontroversial), then you can propose a second with your rationale for changing the deprecated definition?
16:22:49 <Rockyg> ++
16:22:53 <catherineD> markvoelker: +
16:22:55 <hogepodge> markvoelker: sounds good. the first patch separate from the 1.5 schema addition?
16:23:23 <hogepodge> #action hogepodge to add definitions to lexicon
16:23:37 <markvoelker> hogepodge: either way really....that 1.5 patch seems like it's about ripe to land, so maybe we do the lexicon change as a separate patch just to let the 1.5 patch land sooner
16:23:45 <catherineD> refstack update the site with the 1.5 version as it is in the patch ... any futher change we need to revisit and may need to update the site again
16:23:47 <hogepodge> does the schema itself look good to merge? has anyone tested it locally?
16:24:19 <markvoelker> hogepodge: I did (last week, and promptly signed off for the night without clicking submit on my gerrit review...)
16:24:22 <catherineD> I prefer to keep the 1.5 patch as it is and add additional patches for other purposes
16:25:29 <markvoelker> Ok, anything else on 1.5?
16:25:31 <Rockyg> ++ let's not clutter
16:26:04 <catherineD> let's merge the 1.5 patch
16:26:29 <markvoelker> #topic Admin Capabilities
16:26:46 <markvoelker> #link https://review.openstack.org/#/c/299491/ Remove capabilities due to tests required admin credential
16:27:19 <catherineD> I will update the patches to flag the tests (instead of removing them)
16:27:42 <markvoelker> hogepodge: were you able to get a start on refactoring some of those tests?  Need help?
16:28:04 <hogepodge> markvoelker: on neutron tests, no
16:28:16 <hogepodge> markvoelker: since I'm leaving the country for a week on Friday, probably :-)
16:28:27 <markvoelker> hogepodge: =)
16:28:36 <catherineD> markvoelker:  hogepodge:  Still my question is do we allow capabilities with all tests flagged?
16:28:44 <markvoelker> Any takers?  I can probably start picking at a couple of them on Friday.
16:28:48 <hogepodge> catherineD: I'd say yes
16:29:08 <markvoelker> catherineD: Well, keep in mind those tests are not yet required
16:29:17 <catherineD> ok
16:29:22 <hogepodge> markvoelker: I want to start on some tomorrow and tonight too, but my eyes may be bigger than what my fingers can type in that time
16:29:38 <Rockyg> Well, if we think there will be tests before the guideline is approved, yeah.
16:30:05 <catherineD> These are tests in the advisory section of approved guideline (2016.01)
16:30:14 <Rockyg> Ah.
16:30:37 <markvoelker> hogepodge: I know that feeling well. =)  I already took a poke at the test_create_show_list_update_delete_router test in one of my comments, so I'll probably start with that set.
16:30:46 <Rockyg> Still, since advisory, and they are gonna get fixed in .next, this is still broadcating intentions
16:30:50 <hogepodge> based on the conversations with armax, there are definitely capability tests we can have fixed in time for the guideline approval
16:30:50 <catherineD> We should flag them mean while (so users do not spend time debug) while waiting for refactoring
16:31:15 <markvoelker> catherineD: I think it's fine to flag them just to convey info
16:31:43 <catherineD> markvoelker: yup that is goal
16:31:46 <hogepodge> catherineD: in next? as long as we're ok with removing flags in next (since it's advisory and not approved)
16:31:57 <catherineD> alright I will update the patches after this meeting
16:32:04 <hogepodge> catherineD: thanks
16:32:13 <Rockyg> thanks, catherineD
16:32:22 <markvoelker> hogepodge: well, that patchset was against 2016.01
16:32:56 <hogepodge> I guess it doesn't matter since it's advisory
16:33:00 <hogepodge> (the capabilities)
16:33:09 <hogepodge> the flags will have to stick, but they'll be resolved in next
16:33:32 <catherineD> markvoelker: yup I did not want to mix the approved and pending guidelines in these patches expecting a lot of discussion on the topic
16:33:42 <markvoelker> catherineD: ++
16:34:39 <markvoelker> #action catherineD update https://review.openstack.org/#/c/299491/ to use flags
16:35:07 <markvoelker> #action markvoelker to start work on neutron test refactor
16:35:15 <markvoelker> #action hogepodge to enjoy his trip
16:35:28 <catherineD> noted that if we allow all tests flagged in a capability, we violate item #1 in the spec https://review.openstack.org/#/c/317531/2/working_materials/DefCoreSpec.rst
16:36:42 <markvoelker> cathrineD: I'm not so sure...a test might be flagged for any number of reasons (including a bug).  I wouldn't expect us to drop a capability and have to go through another advisory cycle to restore it just because of that
16:37:01 <markvoelker> but we can discuss that in the spec review I think.
16:37:11 <Rockyg> ++
16:37:23 * markvoelker glances at clock and suggests we move on to the other admin-related stuff on the docket today
16:37:43 <markvoelker> #link https://review.openstack.org/#/c/322250/ Remove volume2-v2-qos capability
16:37:48 <catherineD> markvoelker: so should we update the test spec to include language to take care of the case of flagging
16:38:09 <markvoelker> catherineD: possibly so...a good thing to bring up in the discussion of the spec
16:38:28 <catherineD> alright
16:38:45 <markvoelker> This one looks pretty straightforward I think
16:39:24 <markvoelker> hogepodge: here again I wonder if it's worth leaving a note in the working materials just for future reference so the next person evaluating cinder stuff doesn't fall into the same trap?
16:40:00 <hogepodge> Sure, I can do that
16:40:27 <markvoelker> hogepodge: cool, thanks.  I'll re-plus2 it when I see the new patchset.
16:40:28 <catherineD> maybe include a note to https://review.openstack.org/#/c/299491/  which has a lot of conversation about the subject
16:40:45 <hogepodge> +1
16:41:14 <markvoelker> #link https://review.openstack.org/#/c/322253/ Remove volumes-v2-transfer capability (requires multi-tenant)
16:41:51 <markvoelker> here again, looks pretty straightforward...anything we need to discuss on this one?
16:42:47 <markvoelker> On a related note, in spite of the fact that we won't be requiring this capability, thanks to hogepodge for improving the tests anyway so they don't needlessly require admin. =) https://review.openstack.org/#/c/321901/
16:42:58 <hogepodge> Is there a case where transfer between users in a project has meaning?
16:43:15 <markvoelker> hogepodge: hmmm...
16:43:18 <hogepodge> I don't think so, but I could be wrong.
16:44:01 <markvoelker> I guess I can't personally think of a situation when I've really seen that done.  Happy to let it sit for a bit longer and noodle on it though.
16:45:12 * markvoelker makes note to do some research
16:45:31 <markvoelker> Any other discussion on this?
16:46:12 <markvoelker> #topic Rename Working Group (from board meeting guidance)
16:46:50 <markvoelker> So last time we discussed this, "Interop Working Group" or "Interoperability Working Group" seemed to be by far the most popular choice for renaming, but I want to be careful to note that was just a straw poll...
16:47:08 <markvoelker> I think perhaps the best way to proceed is for me to compile a patch making appropirate changes to our docs and push it up to gerrit
16:47:49 <markvoelker> When it gets to a point where it's ready to land and we've agreed a new name, we can also update wiki's, broadcast the change to the relevant aliases, etc before we land it
16:47:55 <hogepodge> It's clear and basic. Task force sounds cool though ;-)
16:48:09 <markvoelker> (this would probably want Board approval, obviously, so there's not a huge rush)
16:49:04 <markvoelker> Any objections to that course of action?
16:50:30 <hogepodge> +1 on that action
16:50:32 <markvoelker> alrighty then, hearing none....
16:50:32 <markvoelker> #action markvoelker begin working on doc update patch for DefCore Committee renaming
16:51:10 <markvoelker> #topic Open Reviews
16:51:49 <markvoelker> We have about nine minutes left, so rather than picking through these one-by-one: are there any that folks particularly want to discuss today in the meeting?
16:53:08 <hogepodge> Compute image flags
16:53:21 * markvoelker yields the floor to hogepodge
16:53:24 <shamail> Based on the new UC charter, we would want to ensure that we are classified as a working group
16:53:33 <hogepodge> Is there any reason to hold that one back?
16:54:59 <hogepodge> Also schema 2, if anyone has thoughts on that. Procedurally it still needs work, but if we're doing a major version update we should use it as an opportunity to possibly fix or add other things
16:55:00 <markvoelker> hogepodge: I'm fine with the tests being flagged.  I'm not sure the Nova-uses-v1 issue is terribly relevant as a rationale (we're more interested in what's exposed to ends users than to nova), but that's probably picking nits.
16:55:44 <hogepodge> I can change it to something else. I'm mainly just trying to reconcile with 01
16:56:30 <hogepodge> shamail ack
16:57:15 <markvoelker> hogepodge: I think our understanding of the image world has evolved a bit so it feels like a good opportunity to express that.  But, like I said, it's probably anit.
16:57:20 <shamail> hi
16:57:48 <markvoelker> shamail: hi
16:58:29 <shamail> nm, I thought hogepodge was asking about something. :)
16:58:35 <markvoelker> =)
16:58:35 <hogepodge> shamail is there a process for officially being a WG?
16:58:47 <shamail> Yes, there is (very lightweight)
16:58:50 <catherineD> hogepodge: ++ on putting major updates to schema 2
16:58:54 <shamail> FYI, here is the draft UC charter: https://docs.google.com/document/d/1QmLOeseAkjBWM_TXsUeKBErNaSHnuZp81II0T71ARfo/edit?usp=sharing
16:59:11 <markvoelker> shamail: thanks
16:59:18 <shamail> To become a WG, you would want to add info on UC wikihttps://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee
16:59:22 <shamail> #link https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee
16:59:25 <markvoelker> #link https://docs.google.com/document/d/1QmLOeseAkjBWM_TXsUeKBErNaSHnuZp81II0T71ARfo/edit?usp=sharing UC charter draft
16:59:32 <shamail> and just email Edgar, Jon, and/or Shilla
16:59:49 <hogepodge> As a board WG are we covered under it?
17:00:10 <shamail> Other requirements are still being refined, but adding to wiki and notifying user committee (probably by emailing user-committee ML) should be sufficient
17:00:32 <shamail> Yes, but it would still be good to add info.
17:00:37 <catherineD> our time is up ..
17:00:47 <shamail> I guess one item that is open is whether defcore consders itself under TC or UC governance
17:00:48 <markvoelker> Indeed.  Over to #openstack-defcore.  Thanks folks
17:00:52 <shamail> (there is no board governance option)
17:00:58 <markvoelker> #endmeeting