15:00:06 <eglute> #startmeeting defcore
15:00:07 <openstack> Meeting started Wed Oct  7 15:00:06 2015 UTC and is due to finish in 60 minutes.  The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:11 <openstack> The meeting name has been set to 'defcore'
15:00:15 <eglute> #chair hogepodge
15:00:19 <openstack> Current chairs: eglute hogepodge
15:00:22 <markvoelker> o/
15:00:25 <eglute> #topic roll call
15:00:25 <hogepodge> o/
15:00:33 <eglute> morning everyone!
15:00:42 <hogepodge> Good morning!
15:00:55 <eglute> raise your hand if you are here for defcore meeting
15:01:04 <eglute> #topic agenda
15:01:05 <markvoelker> Good morning (more morningish than usual for me since I'm on the west coast today)
15:01:23 <eglute> please review today's agenda: #link https://etherpad.openstack.org/p/DefCoreFlag.18
15:01:36 <catherineD> Good morning .o/
15:01:42 <eglute> sorry markvoelker, then this is really early for you, just like for hogepodge!
15:02:00 <kbaikov> o/
15:02:03 <markvoelker> eglute: nah, not really....I'm an early riser, particularly when my internal clock is still on EDT. =)
15:02:41 <eglute> markvoelker you are lucky, i adjust to PST super fast, then hard to switch back
15:03:03 <eglute> anyways, last time we ran out of time, so will start with items we didnt get to
15:03:17 <Guest89741> o/
15:03:18 <eglute> #topic tests that no longer exist in tempest
15:03:23 <markvoelker> #link https://review.openstack.org/#/c/229177/
15:03:44 <scotticus> o/
15:03:50 <eglute> catherineD brought up that one test was renamed
15:04:00 <eglute> and we currently do not have a good way to handle it
15:04:09 <markvoelker> So on this one I think tactically we just need to adjust our documentation, strategically we need to think about how to handle renames.
15:04:30 <hogepodge> a script to generate the required list is the way to go.
15:04:57 <markvoelker> hogepodge: one that runs against whatever version of tempest you have, you mean?
15:04:59 <hogepodge> If possible on the refstack side checking should be done against just idempotent id
15:05:04 <hogepodge> markvoelker: yes
15:05:28 <hogepodge> If a test is showing as failed because of a rename in refstack, we would account for that on the foundation side.
15:05:33 <catherineD> For   that  I am evaluating the SHA that  Mark suggesting .. at  RefStack
15:06:08 <markvoelker> hogepodge: so idempotent ID's aren't unique to tests though, so would have to be some conglomeration of name + id
15:06:15 <hogepodge> idempotent ids only collide when the tests have the same functionality, so there's no loss of generality
15:06:46 <eglute> for each guideline we also have a "procedure" doc. We could specify version there as well. https://github.com/openstack/defcore/blob/master/2015.05/procedure.rst
15:06:53 <catherine_> checking on ID is not possible ... especially with Neutron tests ..
15:07:02 * markvoelker notes that we still don't have one of those for the 2015.07 guideline
15:07:22 <hogepodge> markvoelker: there's a patch up for that
15:07:32 <eglute> yup, there is a patch
15:07:55 <markvoelker> #link https://review.openstack.org/#/c/227645/ < patch to add 2015.07 docs
15:08:22 <eglute> if everyone is ok with it, i will merge it after the meeting
15:08:38 <hogepodge> What would be better is a script. I was working on one in Vancouver and never finished it.
15:08:52 <markvoelker> That patch doesn't have guidance about the SHA though.  Should we just land it and add SHA guidance in follow-up once Catherine verifies it?  Or someone writes the script Chris is suggesting?
15:08:54 <eglute> hogepodge what kind of script do you have in mind
15:09:49 <hogepodge> eglute: something that runs against tempest to produce the required and flagged test lists
15:10:09 <eglute> hogepodge i think that would be great
15:10:10 <hogepodge> so it's up to date against both the tempest tree and the defcore standard
15:11:01 <markvoelker> Who's volunteering to write it? =)
15:11:02 <catherine_> I am not sure how that would work  ... in the list of tests do we include the new or old name?
15:11:05 <eglute> so everyone is ok with having a script as well as listing version in the procedure doc?
15:11:09 <hogepodge> me
15:11:29 <hogepodge> #action hogepodge finish work on required/flagged test script
15:11:36 <eglute> #action hogepodge will write a very nice script, something that runs against tempest to produce the required and flagged test lists
15:11:39 <eglute> hah
15:11:52 <eglute> ok, how about update procedure doc with version?
15:11:56 <hogepodge> eglute: your action item sounds much nicer. :-D
15:12:00 <eglute> :D
15:12:01 <hogepodge> that too
15:12:16 <eglute> anyone is interested in taking that action?
15:12:21 <markvoelker> Like catherine I'm a little curious how this will work, but I'm content to look at the code once proposed to get the big picture.
15:12:23 <hogepodge> eglute: I can do that too
15:12:44 <eglute> #action hogepodge will update procedure doc to include test versions
15:12:54 <markvoelker> Also a little curious how to handle this given that refstack.net will need to show the results properly and that the test lists in the Guideline doc are immutable....
15:13:06 <markvoelker> But it seems like a problem that could be solved
15:13:25 <eglute> markvoelker i think you have valid concerns, lets see what hogepodge comes up with!
15:13:29 <eglute> next item?
15:13:30 <catherine_> Let's give it a trial ...
15:13:32 <hogepodge> Another proposal to address Catherine's concern is to add an "aka": entry to the guideline
15:13:42 <hogepodge> to capture name changes
15:13:55 <eglute> that might be good as well
15:13:56 <markvoelker> Sure.  One more thing: since there are a couple of issues to resolve there it seems like it may take some time for all that to get in place
15:14:04 <hogepodge> markvoelker: catherineD: something like that would resolve the problem, no?
15:14:16 <markvoelker> In the interim I'd suggest Catherine continue testing the SHA to make sure it works, and we update docs to point to it
15:14:23 <eglute> +1
15:14:37 <markvoelker> hogepodge: sounds like a good proposal for schema 1.4
15:14:39 <eglute> also, updating procedure doc will help, until we have other things in place
15:14:49 <eglute> talking of schema! next item
15:14:55 <catherine_> markvoelker: +1 for testing SHA ..
15:15:08 <eglute> #topic cutoff score in schema
15:15:21 <eglute> markvoelker can you give a bried overview
15:15:24 <eglute> brief
15:15:32 <catherine_> hogepodge: aka addition may work ..
15:15:33 <markvoelker> #link https://review.openstack.org/#/c/224868/ Add field to record cutoff score
15:15:50 <markvoelker> Basically this adds a field in the schema to record the cutoff score we used when deciding what to make required in a Guideline
15:16:01 <markvoelker> (note: only the cutoff for required, not for advisory)
15:16:43 <markvoelker> The general idea is to help with transparency and to help us score fairly
15:16:55 <catherine_> +1
15:17:13 <hogepodge> no objections
15:18:12 <eglute> so my only concern is that the cutoff score has been more as a recommendation, not a requirement. ie, if score is high enough, does not mean capability would make it as required. thoughts?
15:19:16 <markvoelker> We are required to select a cutoff score (http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n109) so seems like making that visible is good for transparency
15:19:32 <rockyg> o/
15:20:12 <eglute> markvoelker good point.
15:20:58 <eglute> #action everyone review #https://review.openstack.org/#/c/224868/ by end of week and comment
15:21:25 <eglute> #topic tokyo working sessions
15:21:49 <eglute> we have 2 working sessions, we started preliminary agenda #link https://etherpad.openstack.org/p/DefCoreFlagTokyo
15:22:03 <eglute> please review agenda and add/update
15:22:35 <eglute> if we have too many items on the agenda, we can hold a separate brief meeting to review the agenda and prioritize
15:22:55 <markvoelker> eglute: where should we add/update?  Is there an etherpad or something?
15:23:06 <markvoelker> oh, duh...first link
15:23:09 <eglute> heh
15:23:11 <markvoelker> looked right past it. =)
15:23:32 <eglute> sorry dont mean to rush through things, but still a lot to cover today
15:23:34 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreFlagTokyo Tokyo summit working session agenda
15:23:47 <markvoelker> No worries, let's move on
15:24:22 <eglute> also, if you know of other tokyo defcore/refstack sessions, update today's etherpad or add it to the agenda for tokyo
15:24:40 <eglute> #topic review spec for refstack registration
15:25:04 <eglute> #link https://review.openstack.org/#/c/226902/
15:25:08 <rockyg> there's one proposed for cross project but won't be scheduled for a bit yet
15:25:24 <eglute> rockyg cool, update when you know the time
15:25:41 <eglute> markvoelker can you give a brief summary of the proposed spec?
15:25:49 <markvoelker> So a while back Catherine asked us to write a draft proposal for how to handle vendor registration/affiliation in refstack.
15:26:05 <markvoelker> She was extremely patient while I was busy with other things, and eventually this came out of my keyboard. =)
15:26:36 <markvoelker> There's some good discussion in the comments about how to deal with user affiliation data/verification, and whether vendor *products* need to be "first class citizens"
15:26:47 <markvoelker> And also some questions that probably need answers from the Foundation
15:27:04 <catherine_> Thank you for the spec ...  I feel like the vendor registration topic is a good one for face-2-face at the summit ...
15:27:41 <markvoelker> catherine_: +1.  Chris, if you haven't already it would be good to peruse some of the comments there if you can speak to the Foundation's capabilities/feelings about a couple of things
15:27:58 <eglute> +1 for the summit discussion
15:28:06 <markvoelker> (or point us to someone who can)
15:28:53 <hogepodge> ok
15:28:58 <eglute> ok, so we will move this topic to F2F
15:29:15 <catherine_> I will add the topic to the summit etherpad ..
15:29:23 <eglute> thanks catherine_
15:29:38 <eglute> now we can go back to scoring, unless there is something you want to move ahead on the agenda
15:29:52 <eglute> #topic scoring
15:30:23 <eglute> cinder did not receive a ton of comments, #link https://review.openstack.org/#/c/221631/
15:30:25 <catherine_> eglute: thanks for allowing time to discuss the RefStack related topics ... :-)
15:30:38 <eglute> catherine_ this seems very related!
15:31:15 <eglute> for cinder, i think there was one comment about extra characters left in,
15:31:21 <eglute> is it ready otherwise/
15:31:23 <eglute> ?
15:31:39 <hogepodge> eglute: I just updated that patch before the meeting, so good to go
15:31:57 <markvoelker> eglute: it also needs the achievements added to teh json and a rebase
15:31:59 <eglute> cinder? i dont see an update
15:32:08 <eglute> #link https://review.openstack.org/#/c/221631/
15:32:46 <rockyg> ithink it happend 9/28
15:33:02 <markvoelker> I see a few other issues in the json too....commenting now
15:33:18 <markvoelker> But I think we've had sufficient soak time to generally agree on what should go into it.
15:33:30 <hogepodge> oh yeah, nevermind, rebase failed.
15:33:45 <eglute> ok, then will wait for the cleanup, and then merge at the end of the week, or as soon as all the issues are fixed
15:34:29 <hogepodge> The hour after the meeting is devoted to cleaning up the cinder, glance, and keystone patches for final review.
15:34:36 <eglute> :)
15:34:54 <eglute> talking of glance!
15:34:58 <eglute> #link https://review.openstack.org/#/c/213353/
15:35:28 <eglute> rockyg i know you raised some concerns that markvoelker responded.
15:35:54 <rockyg> Question:  so if the vendors have underlying code that allow v2 api to work, does that make it acceptable for inclusion?
15:36:25 <rockyg> the discussion on the mailing list has both cinder and nova saying their code base doesn't work with v2
15:36:25 <markvoelker> rockyg: not sure what you mean.....v2 does work with upstream code
15:36:49 <markvoelker> YEs, they use the v1 API.  That doesn't mean v1 has to be exposed to end users or that other projects have to use v2 though.
15:37:05 <rockyg> Nope.  v2 tests work, but the capability has not been added to work with either project.  Neither uses v2 api
15:37:40 <markvoelker> rockyg: I'm not seeing why that would prevent v2 from being required to be exposed to end users.
15:37:40 <rockyg> which pretty much mean that the only people who *do* have it working are outside of the dev community
15:37:51 <markvoelker> rockyg: huh?
15:38:01 <rockyg> the nova client and the cinder client use v1
15:38:11 <rockyg> because v2 breaks
15:38:28 <rockyg> no v2 is called from either code base at the moment
15:38:40 <rockyg> it's an api sole restricted to glance itself
15:39:24 <markvoelker> So, I'm still not seeing why it matters that nova and cinder talk to glance over v1.  Maybe that impacts the clients score, which has been discussed already in the review.
15:39:29 <rockyg> That's what dhellmann's email thread was about.
15:39:33 <markvoelker> But v2 works for end users and has for some time
15:39:40 <markvoelker> And in fact most products out there support it
15:39:44 <markvoelker> And don't need special code to do so
15:39:50 <markvoelker> Also noted in the review
15:40:04 <markvoelker> DefCore specifies what end users can rely on being present
15:40:10 <rockyg> well, if our own projects are not using it yet, how much in use is it really?
15:40:16 <markvoelker> Quite a lot
15:40:40 <rockyg> which means the code supporting it is all vendors, not dev community.
15:40:50 <markvoelker> Monty's notes for example: on 11 public clouds it is the only way for you to upload an image
15:41:04 <rockyg> That's why I asked if it's ok to use out of tree code, vendor code, to make it work
15:41:17 <hogepodge> it's not vendor code making that work
15:41:24 <markvoelker> rockyg: There is no out-of-tree code involved in v2 working
15:41:28 <rockyg> According to the dev thread, it is
15:41:34 <hogepodge> it's configuration to expose v2, which is enabled by default
15:42:00 <rockyg> I don't think v2 is enabled by default.
15:42:04 <markvoelker> rockyg: I'm not reading that from the dev thread at all.
15:42:09 <rockyg> If it is, it just happended in the gate
15:42:24 <rockyg> .  I'm getting that from a glance core and others
15:42:30 <markvoelker> rockyg: if someone were saying they had nova and cinder talking to glance via v2, that would be out of tree code
15:42:59 <rockyg> create image needs to talk to nova.
15:42:59 <markvoelker> But the concern here is what is exposed to end users, not to nova/cinder.  If you want to enable the v2 API for tenants, that works.  Out of the box.  Has for some time.
15:43:16 <markvoelker> No it doesn't.  Other way around.
15:43:28 <markvoelker> If you want to use the nova create image API, that talks to glance (via v1)
15:43:43 <rockyg> ok, so then nova calls image-create?  It is using v1
15:43:49 <markvoelker> If you want to upload an image to glance directly (e.g. not create one from a running instance) you can do that with v2 directly to cinder
15:43:51 <markvoelker> err, glance
15:44:02 <hogepodge> our goal should be to eliminate nova create image api, and other proxy apis. Way too much pain there
15:44:12 <rockyg> but to create an image, noav and glance have to talk.  the only way for that to happen is v1
15:44:35 <markvoelker> None of these capabilities are concerned with creating an image from an existing instance.
15:45:29 <hogepodge> We should also foster interoperability through stable apis that will have future support. In 9 months, the earliest that these can be required, glance v1 will be entirely done. Cinder v1 also. This is in part because of the problems we as a committee have exposed.
15:46:05 <markvoelker> rockyg: If you want to create an image, nova and glance basically don't have to talk.  If you want to create an image *from and existing instance* then they do.
15:46:30 <markvoelker> hogepodge: is glance actually going to deprecate v1?  I haven't actually heard that....
15:46:37 <rockyg> I'll remove my -1.  for advisory, but don't be surprised if it stays advisory for more than one release.  There are few to any client tests and the code doesn't exist in the other projects which mean the tempest tests don't exercise the broken areas.
15:46:44 <hogepodge> making glance v2 and cinder v2 advisory (ane keystonve v3) starting in January only helps our interoperability efforts by aligning us with the community and tc, sending a clear message as to our intentions
15:46:52 <rockyg> But, it may get the devs to get it working.
15:47:11 <eglute> i agree with hogepodge. I think as is, is ok for advisory. remember that just because something is advisory, does not mean it will be required next cycle. if it is still an issue in 6 months, we will revisit.
15:47:12 <markvoelker> rockyg: which of the tests that are listed in the json are not used by devs?
15:47:15 <rockyg> Just don't expect a 6 month turnaround.
15:47:56 <hogepodge> I've seen some pretty amazing 6 month turnarounds in the last year. More than one.
15:48:04 <rockyg> It's not that the tests aren't used, it's that they don't exercise what's not there
15:48:36 <eglute> for the sake of time, lets take this discussion to defcore irc channel
15:48:51 <eglute> i would like to go over identity again
15:48:54 <eglute> #link https://review.openstack.org/#/c/213330/
15:49:17 <eglute> this also a bit controversial issue,
15:49:24 <eglute> and has a lot of -
15:49:26 <eglute> -1
15:49:27 <rockyg> I really think the api discussion needs to happen f2f, which is why I'm taking my -1 away and letting the advisory go through
15:49:46 <eglute> thanks rockyg
15:50:00 <eglute> can you update the agenda for tokyo?
15:50:21 <eglute> for identity patch, same thing, versions.
15:50:45 <eglute> to move forward, i suggest updating the patch to drop v2
15:50:52 <markvoelker> Yeah, I noticed the incoming PTL reversed his vote on this one.  I'm ok with removing v2, though I would really, really like to see the project deprecate it if they're saying nobody should use it anymore.  Sounds like Steve is going to try to make that happen, which is good.
15:51:01 <rockyg> I think we need a *serious* discussion about versions with dev at Tokyo.
15:51:33 <eglute> i agree with you markvoelker they should work on deprecating it
15:52:00 <rockyg> I think that's what most of the issues are over and the dev community is just realizing the implications with the gate and codebase of the various projects going to new api/s
15:52:34 <eglute> i am sure we will have more versions discussions in the future, so we will need to find a good way to work with these issues... or with the devs, or both
15:53:07 <eglute> i am very happy to see PTLs commenting on these patches, hopefully this trend continues
15:53:15 <hogepodge> we need to think about existing v2/v3 tests for tokens too
15:53:35 <hogepodge> I can deprecate them in next
15:53:37 <eglute> hogepodge for this guideline or the next
15:53:43 <rockyg> added to agenda as general versions handling discussion
15:53:53 <eglute> thanks rockyg
15:53:53 <markvoelker> hogepodge: If we're not going to include v2 even as advisory, then we should deprecate the existing v2 stuff in this patch too.
15:53:59 <markvoelker> It's all of one test I think
15:54:06 <hogepodge> if a vendor is running into a v2/v3 testing issue I'd recommend they propose a flag
15:54:17 <hogepodge> markvoelker: +1
15:54:36 <catherineD> markvoelker: +1 on revmoving v2 token test from requirement ...
15:55:10 <markvoelker> On that note, maybe this is a good time to mention an item that's actually later on the agenda (it's quick, promise)
15:55:25 <markvoelker> Is anyone tuning into API WG meetings at all?
15:55:40 <hogepodge> no
15:55:46 <markvoelker> The TC has some guidance about feature deprecation that's useful for API transitions, and the API WG I think has been planning to come up with a plan
15:55:52 <rockyg> just following the patches
15:55:59 <markvoelker> I think our experience here would be useful in that conversation
15:56:02 <eglute> #topic apis
15:56:16 <markvoelker> If nobody else is, I'm happy to liaise with them...
15:56:25 <eglute> thank you markvoelker that would be great
15:56:49 <eglute> #action markvoelker will act as a liaison between defcore and api wg
15:56:57 <markvoelker> Ok, sounds like a plan.  See, told you that was a quick one. =)
15:56:58 <rockyg> please.  I'm mostly focused on where it intersects logging
15:57:15 <eglute> ok, so back to identity... ok to drop v2 and move forward?
15:57:34 <rockyg> yah.
15:57:55 <eglute> cool! i think hogepodge already volunteered to make that change
15:57:59 <markvoelker> I'm fine with that.  I'd also like to be present when keystone discusses deprecating v2. =)
15:58:04 <eglute> 2 min left, any last words?
15:58:09 <catherineD> +2
15:58:19 <hogepodge> Two more meeting before Tokyo.
15:58:28 <hogepodge> s/meeting/meetings/
15:58:35 <eglute> i will not be able to attend either,
15:58:45 <hogepodge> I'll be here for both.
15:58:48 <eglute> because of the conference/other meetings
15:58:49 <rockyg> we might consider a defcore/crossproject dinner for a longer discussion on versions
15:58:50 <eglute> thanks hogepodge
15:59:14 <rockyg> if we can pull it off, we might get better info for moving forward
15:59:29 <eglute> rockyg for moving forward on apis?
15:59:33 <rockyg> or breakfast
16:00:07 <rockyg> the versioning stuff.  Get a senior dev from each project with versions to talk about process to make it work for all of us
16:00:17 <eglute> rockyg lets plan on that. but not for breakfast.
16:00:25 <eglute> great discussion today, thanks everyone!
16:00:26 <rockyg> agreed ;-)
16:00:28 <eglute> #endmeeting