14:59:46 #startmeeting defcore 14:59:47 Meeting started Wed Aug 19 14:59:46 2015 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:59:51 The meeting name has been set to 'defcore' 14:59:57 #chair zehicle 14:59:57 Current chairs: eglute zehicle 15:00:01 o/ 15:00:02 o/ 15:00:09 Hello Everyone! 15:00:34 #topic agenda 15:00:39 #link https://etherpad.openstack.org/p/DefCoreFlag.11 15:00:56 please review and add if you think anything is missing 15:01:10 hogepodge are you around? 15:01:24 o/ 15:01:52 hogepodge, was in PAO yesterday 15:02:24 i think hogepodge had added the first agenda item, carry over from last week 15:02:41 "Suitability of In Tree Swift Functional Tests" 15:02:58 I have to jump off at :30 15:03:20 ok, zehicle do you want to cover any items before you leave 15:03:27 let's hold that till he's online 15:03:36 sounds good 15:04:30 actially, looks like there are only 4 of us here 15:04:38 roll call? 15:04:45 ok, roll call 15:04:49 o/ 15:04:50 o/ 15:04:51 o/ 15:04:57 o/ 15:05:11 thanks markvoelker and catherine_d|1 15:05:16 looks like still only 4 15:05:16 * markvoelker notes that this week is both linuxcon and the operator's midcycle sprint 15:05:37 yy 15:05:40 * eglute thinks is a busy week 15:05:52 we can talk about the Vendor Config patch 15:05:57 so, do we want to go over any items, or hold off? 15:06:29 i know markvoelker has been doing a lot work with capabilities 15:06:52 yy, is there something that we can move forward or are we still at reviewing stage? 15:07:38 The network scoring is getting some feedback--if you haven't chimed in yet, more is welcome 15:07:38 sigh, just realized my comments on #link https://review.openstack.org/#/c/207209/ did not post until just now 15:07:41 sorry markvoelker 15:07:51 I'm not sure anyone has reviewed the scoring script yet other than Egle 15:08:08 (I just found a minor bug which I'll fix as soon as the meeting is over) 15:08:12 I looked at the code and it seems ok. did not get a chance to run it so did not post a vorte 15:08:35 markvoelker i will review/run it again after you fix 15:08:36 I'm happy to +2 it on visual since it it's not critical path 15:09:09 after the fix, I'll be able to test it and then merge 15:09:10 cool, thanks folks 15:09:16 I am working the heat capability patch and have questions ... 15:09:24 go ahead catherine_d|1 15:09:29 would like to apply pep9000 too it 15:10:07 * zehicle mumbles, over 9000 is that even possible? 15:10:46 1) all of us are working on the scoring.txt file and we need to constantly rebase ... should we name the file differently like heat-scoring.txt until final stage? 15:11:26 hm, that actually sounds like a good idea 15:11:40 I'm ambivalent on that. The rebases are trivially easy so it doesn't cost me much. But it's all working materials so if you want to separate them I think that's probably fine too. 15:11:41 should we take the patch as is 15:11:49 and then allow people to make line changes? 15:11:50 2) can we update the capability name on the spreadsheet ... some of the capability name on the heat component do not make sense .. if so what is the procedure ... 15:12:09 I was assuming that we'd start from a base file 15:12:20 so that each patch could be targeted as a single item 15:12:34 +1 zehicle 15:12:57 zehicle: that's what we're doing. There's a blank scoring sheet in the repo already, and currently three patches in review to add to it. 15:13:17 sorry, ok 15:13:24 I think Catherine's just saying that if my patch lands first, she has to rebase hers 15:13:38 And if one of Chris's then lands, she has to revbase again 15:13:55 ah, ok. thanks 15:14:04 But as I say, the rebases are trivially easy so in practice I don't mind it. 15:14:07 nothing to be done about that 15:14:10 yes we start on a base file but our patch makes change to the same file (scoring.txt) and we do not incldue each other's sfuff ... like the identity does not incldue network but use the same name 15:14:52 so we still use the same file name? 15:15:03 how about keeping scoring for different components as sepaarete files? 15:15:23 that might be easier to manage going forward 15:15:53 Again, I'm ambivalent. =) To me it seems like not a lot of work to keep them all together, but I don't mind if others have strong opinions about separating. 15:15:59 o/ 15:16:11 eglute: yes that is keep individual file at working stage and then a final patch is to merge the file at the end 15:16:38 to an extent, I think it would be great to have the patches land so we can discuss individual items 15:16:39 i am thinking even for final patch keep them separated out 15:17:19 I'm trying to track the discussion on the networking ... is it a meta discussion or specific about individual capabilities 15:17:38 eglute, +1 15:17:51 zehicle: you mean the discussion in the review? 15:17:54 I'd like to see the working materials accepted 15:17:58 markvoelker, yes 15:18:15 so that discussions could focus on individual caps when possible 15:18:32 zehicle: markvoelker: I think that is the kind of discussion we need for all of the component 15:18:40 zehicle: a bit of both. Jean-Daniel raised some points about two of the four "buckets" of capabilties there. 15:18:47 but it looks like the discussion is meta 15:18:58 markvoelker, I'm reading that part now 15:20:46 we'll always have people who are getting used to the process and need to ask questions. 15:21:22 I think I'm in favor of splitting the files and merging them 15:21:33 then having patches for discussion 15:21:47 ok 15:22:02 but I'm not ready to fight for that, just me sense of what's easiest/clearest 15:22:36 what is the final decision? using the same file name or separate? I can operate either way just need to submit a patch for heat 15:22:37 markvoelker, catherine_d|1 hogepodge you have horses in that race - it's really your call 15:22:45 yeah, i think we can change later if it is too complicated/not clear 15:23:15 in the end, all the changes end up in 2015.next anyway 15:23:35 I think I mildly prefer keeping them together, but like I said: no strong opinion and happy to be flexible if others have strong opinions. 15:23:35 but that won't have the rebase challenges 15:23:39 I would ask one thing though: 15:24:10 If we do decide to split them, could we keep the existing network patch as-is? We have a reasonably good discussion going in that review and I hate to disrupt it with a process change. 15:24:21 markvoelker, +1 15:24:30 Just use the same name and make it one rebased file. I'm happy with that 15:24:47 markvoelker +1 15:24:53 wont git mv keep the history on the file? 15:26:02 but it's just a convenience, so I don't have too strong an opinion either way 15:27:20 have to go in a min - can we move on to the Vendor Config patch? 15:27:42 Ok, sort of sounds like no real strong opinions one way or the other, so I'll suggest we just leave it as-is, try it out for a while, and revisit later once we've had some experience working with it. 15:27:54 zehicle: +1 15:28:03 markvoelker, +1 on leaving it for now. 15:28:14 #topic vendor config patch 15:28:16 if someone wants to split it then _just do it_ for your section 15:28:29 no one will be upset 15:28:32 :) 15:29:26 ok, so require vendors to submit configs 15:29:34 #link https://review.openstack.org/#/c/207209/ 15:29:35 for the Vendor Config patch, my goal was to have vendors explain what they are supporting 15:29:52 so more about supported config than tested config 15:30:14 We actually had a pretty good/healthy discussion about this last week in the meeting I think... 15:30:16 with the assumption that if they support it then the results _should_ be repeatable on their config 15:30:19 Hmm... 15:30:33 I had a chance to see the review 15:30:38 and discussion 15:30:39 And now that I think about it, Chris and I had an AI to start an ML thread and I think we both thought the other was going to start it.=) 15:30:55 I think you sent it out there 15:30:57 oops 15:31:12 must have been on the patch 15:31:49 well, do you think it is still worth having ML discussion? 15:31:57 I do think that we need to collect information from the Vendors about what they support 15:32:26 more specifically, about what configuration will reproduce the results they posted 15:32:57 they could choose to post the exact configuration or choose to post something more production class 15:33:01 zehicle: so I think we talked a bit about that last week too. To sum it up briefly, I think there's concern that one test result can't realistically show "what they support"...in most cases it shows a very small subset 15:33:05 but there's an element of trust 15:33:22 And the Marketplace would actually be a much better forum for showcasing requirements 15:33:25 they can submit multiple results 15:33:41 E.g. in the Marketplace, we can provide a place to link to datasheets, reference architectures, etc. 15:33:47 as long as there's a consistent set of data for comparision 15:33:59 not just the vendor's choice 15:34:17 zehicle: sure, the Marketplace folks could define a set of things that vendors provide when they want to appear. 15:34:29 agreed 15:34:43 this just gives the Foundation the authority as part of the process to require it 15:34:48 (I'm not wed to the idea of using the Marketplace for this, BTW, it was just the most viable option that came up last week) 15:34:57 (If there's a better place, I'm all ears....) 15:35:19 I suspect the marketplace will have a lot of, um, marketing on it 15:35:33 I'd like to have DefCore results be somewhat more generic 15:35:54 that was my thinking when we discussed it face to face 15:35:58 I'm fine with that, but product requirements aren't really defcore results. 15:36:15 agreed - I was looking for minimum specs to reproduce results 15:37:00 that was the essence of the discussion - we want vendors to explain what customers would need to reproduce 15:37:19 its a bit strange with the hosted services but likely useful information 15:37:51 zehicle: So maybe we should make the patch say that instead of "The objective is for users to understand the requirements for deployable products and to know the resources available on hosted products."? 15:38:06 Because those seem like two really different things... 15:38:22 perhaps 15:38:54 If we are loooking for interop, then you likely need to know the background either way 15:39:38 If this is about establishing interoperability, I'd argue that this is the wrong way to go about collecting data. If it's about helping people understand how the test run used for certification was done, this might be fine. 15:40:06 * zehicle gtr 15:40:14 I need to drop off for a bit. I'll try to be back online before the meeting ends. 15:40:27 thanks zehicle 15:41:04 Ok, so should we go ahead and take this to the ML? I'll take the AI to start that thread if we want to. 15:41:05 quick word on the topic though, Foundation wants deployment information in some way. 15:41:08 so i think we would still benefit from ML discussion, even if it would be to give others a chance to chime in. markvoelker would you start it? 15:41:18 sure 15:41:39 Chris: it would be good to know what they want to use that info for....I think we've had more than one potential use for it come up now. 15:41:45 hogepodge: ^^ 15:41:46 #action markvoelker hogepodge will start ML discussion regarding vendors submitting config info 15:43:28 i am guessing hogepodge walked off for a bit 15:43:49 markvoelker and catherine_d|1 do you want to do the refstack updates? 15:44:19 eglute: I still have a question about capability scoring ... 15:44:28 ok, go for it 15:44:48 #topic capabilities scoring 15:45:15 so what is the procedure if I need to change the capability name (for example heat) ... do i just update the spreadsheet then send the patch? some of the names do not make sense.. 15:45:26 * markvoelker just fixed that bug with the scoring script btw 15:45:46 * eglute thanks markvoelker 15:46:19 catherine_d|1: I think that's fine. We already changed the network names anyway (we changed "network-" to "networks-") 15:47:09 ok so I will make the change on the heat section of the spreadsheet before submitting the heat scoring patch ... 15:47:22 catherine_d|1: sounds good 15:47:42 +1 15:48:00 eglute: I am ready for the next topic :-) 15:48:05 great! 15:48:41 since it is only 3 of us, we can talk more scoring. but i would like to hear about refstack first 15:48:48 what do you think? 15:48:52 +1 15:48:55 #topic refstack 15:49:27 catherine_d|1 did you add that item? 15:49:34 o/ 15:49:47 wb hogepodge 15:50:07 hogepodge: what is the personel change in RefStack? 15:50:28 It's likely Sergei will be reassigned 15:50:28 sorry, i assumed it was catherine_d|1 15:50:47 The mirantis contract for that work ends this week 15:51:01 oh no ... 15:51:18 hogepodge: no way we can continue ...? 15:51:49 Not from our side 15:52:15 was it a contract from foundation side? 15:52:25 that only leave IBM on RefStack development nit very good for a community project .... 15:52:37 nit -> not 15:53:03 Yes 15:53:04 I really do not want it to be an IBM only project ... 15:53:18 * markvoelker was completely unaware of that contract in the first place 15:53:27 We can figure out how to get more participation 15:53:27 i will send email to Sam and Daryl to see if they will be helping with the project 15:53:46 * eglute was not aware of the contract either 15:54:17 it was a contract starting from Dell ... 15:54:33 catherine_d|1 what do you mean? 15:55:44 I think Dell hire developers to work on RefStack on their behalf 15:55:53 ok, so regardless of the contract: we need more participation in refstack. I'll see if I can poke anyone... 15:56:11 markvoelker: +2 ... 15:56:49 catherine_d|1 could you send an email to defcore mailing list and maybe QE list asking for people to get more involved? 15:56:57 I am asking internally as well 15:57:18 will do .. 15:57:24 thank you catherine_d|1 15:57:54 #action catherine_d|1 send an email to mailing lists asking for people to help with refstack 15:58:11 we have 2 minutes, any last items? 15:58:33 It's not a foregone conclusion, but a likelihood 15:58:34 #action everyone go review scoring script and let's merge that sucker 15:58:44 markvoelker yes 15:59:28 thanks everyone! 15:59:31 #endmeeting