15:59:48 #startmeeting defcore 15:59:48 Meeting started Wed Feb 3 15:59:48 2016 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:59:51 The meeting name has been set to 'defcore' 15:59:54 o/ 15:59:56 o/ 16:00:09 #agenda 16:00:12 #link https://etherpad.openstack.org/p/DefCoreRing.11 16:00:28 o/ 16:00:33 Hello Everyone, wave your hand if you are here for defcore meeting! o/ 16:00:53 also, please review agenda and add/update as needed 16:01:07 *waves* 16:01:23 #topic DefCore CoChair elections 16:01:24 o/ 16:01:44 o/ 16:01:51 Since we had only one nomination, we are not going to have formal elections 16:02:17 I am pleased to announce that markvoelker_ will be our new co-chair for defcore 16:02:27 #chair markvoelker_ 16:02:28 Current chairs: eglute markvoelker_ 16:02:41 excellent news :D 16:02:48 markvoelker_: congrats! 16:02:54 markvoelker_: Congrats! 16:02:55 markvoelker_: congratulations :D 16:03:01 markvoelker_: sweet! 16:03:05 =) Thanks folks, I hope this will be a productive cycle. 16:03:07 indeed, markvoelker_ has been very involved and active in defcore for a long time 16:03:36 i look forward to working with markvoelker_ 16:05:20 we will need to update the election process in the process document for future elections, since the last change didnt get much time for reviews, this time we will start planning for it sooner 16:05:30 but not today :) 16:05:51 if you do have feedback regarding election process, do let us know, via email or IRC 16:06:33 if there are no further comments/questions regarding elections, we can move to the next topic 16:06:35 Volker, this is SammyD. Congrats. :-) 16:07:09 #topic "Biggest barriers to interop" report for TC/UC 16:07:26 markvoelker_ this is the topic we didnt get a chance to discuss last meeting 16:07:34 * markvoelker_ casuaully notes that he and hogepodge have submitted a Summit speaking proposal on this topic as well 16:07:48 markvoelker_ on elections? 16:08:00 barriers to interop 16:08:03 eglute: no, biggest barriers to interop 16:08:09 cool! 16:08:19 this is your topic, would you give us overview? 16:08:22 Sure 16:08:56 So, some time ago we discussed that there were a lot of barriers to interoperability to overcome...so, some triage and summary would be good 16:09:23 Specifically, we'd like to periodically inform the TC and UC of what we think the biggest barriers are so we can focus efforts at breaking them down 16:09:40 We haven't decided on a timetable, a format, etc yet. I think it's time we start. 16:10:32 what do you propose? 16:10:39 Just as a reminder, these barriers may include things DefCore has not (yet?) addressed...such as image formats (think qcow vs vmdk for example) 16:11:21 My general thinking has been that I'd like to do this on a six-month cadence and match it toward the start of the development cycle 16:11:53 That way projects teams can be informed of issues while they're still deciding on goals for the development cylce, and there's time to write BP's/bugs/etc and get them implemented in the next release. 16:12:30 That timing makes sense to me 16:13:01 If we bound the report at six months, then I've been thinking a "Top 5" list feels about the right sized bite to chew. I could see a "Top 10" but realistically I'm not sure all of thsoe would get tackled anyway. 16:13:20 i think top 5 is a good start 16:13:21 E.g. I'd rather have more wood behind fewer arrows 16:13:57 that makes sense to me 16:14:18 A top 5 would be a good start 16:14:19 Oh, and also: if we were to finish up the report ahead of the Summit, it's a thing we could talk about while everyone is in one place, obviously. 16:14:25 That seems like a reasonable approach to me 16:14:39 +1 16:14:42 +1 16:15:04 And gives folks a chance to give feedback on our priorities 16:15:16 So, if we generally agree on the direction, I think the best thing to do would be to spend some time on this at the midcycle next month. 16:15:40 * rockyg sneaks in late and sits in the back 16:15:49 I would be happy to take an AI to come to the midcycle with a list of some of what I think are the biggest issues to get the conversation started, and we can start winnowing down from there. 16:15:52 that sounds good 16:16:03 #link https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle 16:16:10 And you all can tell me what I forgot to put on the list, of course. =) 16:16:49 yes, that sounds good 16:17:02 I'd also like to solicit some opinions from others in the community. We can talk about how to go about that at the midcycle too I guess 16:17:21 #action markvoelker_ will come up with a starting list for midcycle of things that are top barriers for interop 16:17:41 Personally I want to avoid surveys as we seem to have an awful lot of those running around lately, but it might make sense to start including some questions on the annual user survey as data points. 16:18:25 can we take anything from last years study as a starting point? 16:18:27 In the meantime I imagine the UC would probably be willing to talk with us, and certainly some TC members have been very vocal about what they see as issues. 16:19:49 foundation wants to discourage surveys. If there's information you want, contact heidi joy at the foundation and ask to see what can be incorporated into the user survey 16:19:51 eglute: Well, there were no specific questions around interoperability, though there were some sort of "adjacencies". 16:20:04 hogepodge: ++ 16:20:04 * eglute wonders if it is too late to invite someone from user committee to the midcycle 16:22:40 * markvoelker_ thinks that's about all he had to say on the topic for today 16:22:57 thanks markvoelker_ 16:23:00 Thanks markvoelker_! 16:23:10 i think this will be really good discussion during midcycle 16:23:30 we could send out emails to other openstack mailing lists for input 16:24:24 catherine_d|1 are you ready to talk about refstack? 16:24:37 eglute: yes 16:24:42 #topic refstack 16:24:53 thanks! please go ahead 16:24:56 there are some other reports too, I can forward them on 16:25:08 thank you hogepodge, please do so! 16:25:27 RefStack needs some guidance fron DefCore 16:26:17 topic 1: vendor self-registration vs vendor list imported by the Foundation members 16:27:16 This topic was discussed during the Mitaka summit. DefCore guidance is to have the list imported. 16:27:49 We want to revisit and confirm on the option 16:28:21 * markvoelker_ would defer to hogepodge on this since ultimately it's probably him who was going to be providing said list 16:28:23 hogepodge what is your current preference? since the import/getting a list would be your task most likely 16:28:49 if we go the self-registrarion route, vendor will not be shown until a foundation member has approved it. 16:28:50 I'd prever vendors create their own profiles, then we approve them 16:29:03 he self registration would need a foundation admin to approve before it would become official 16:29:13 makes vendors responsible for the correctness of their own information, but give us a chance to review to make sure nobody is spoofing 16:29:14 ^he^the 16:29:21 However, immediately in the Mitaka release, RefStack does not provide verification steps, auditability trail (who has approved it), or notification. 16:30:34 so right now, once the info has been input to refstack, foundtion would have to do all the manual steps to verify before accepting 16:31:16 rockyg: yes.. thank! 16:32:41 That also means hogepodge would also have to check regularly to see if any vendor submitted a regisration (request) 16:32:57 They'll need to notify us 16:33:23 that should be easy enough to document in refstack 16:33:58 we also do not track who makes the approval ... of course, it won't be a problem if hogepodge: is the only one to do so .. 16:34:48 And, of course, there won't be any signed docs in the refstack db, so the foundation would still have to collect all that stuff. 16:34:49 hogepodge: yea we will document it ... but won't have enough time for code support in Mitaka 16:37:25 ok, anything else on this? 16:37:57 #topic MidCycle Agenda Planning 16:37:58 which option should RefStack proceed? 16:38:17 markvoelker_: we also have one more topic for RefStack :-) 16:38:30 catherine_dl1: Ah, ok 16:38:42 #topic Refstack 16:39:07 Product types 16:39:35 catherine_dl1: Sounds like hogepodge wants to go self-registration, so we'll record that as current consensus unless anyone differs 16:39:52 Once a vendor registered, the members of the vendor can register products ... 16:40:59 question: should the product types require to match with those shown in the OpenStack Marketplace (distro, public_cloud, hosted_private_cloud) ? 16:41:30 that sound like a reasonable option to me 16:41:43 that is should RefStack require the vendor to declare types at registation time? 16:41:55 hogepodge what is your opinion? 16:42:07 three, to match the marketplace 16:42:16 +1 16:42:27 how does a distro differs from a public_cloud if they deploy a distro one? 16:42:43 markvoelker_: thx ... RefStack will take the self-registration route 16:43:02 I'm curious: does RefStack actually need a type? E.g. if it has a pointer to the MarketPlace entry, does it need to duplicate the type? 16:43:26 Sort of feels like if the MarketPlace ever adds/removes types, we'd have a bit of a mess to clean up. 16:43:39 If we're actually using the type for something though, maybe that makes sense... 16:43:55 gema: markvoelker_: RefStack needs a type to enforce whether cloud URL is required.... Cloud URL is required for public_cloud but not for the others 16:44:05 ok 16:44:31 also I am thinking down the road ... marketplace can post the link on RefStack for test results 16:44:45 catherine_d|1: ok, I was trying to figure out what is the difference in terms of certification of having an ubuntu distro certification vs someone that has deployed a public cloud with our distro 16:44:50 would they need to certify as well? 16:45:23 gema yes, as it would be a separate product 16:45:45 eglute: how is a distro a product, then, it allows to deploy so many different clouds 16:46:18 good question. that is why we had talked about asking for deployment details when vendors ceritfy 16:46:29 ah, ok, I can talk for us then :) 16:47:22 we have talked about asking for reference architecture/details of what is being deployed. i think this is something we should bring up during midcycle 16:47:34 +1 16:47:51 eglute: +1 16:48:00 catherine_d|1 did we answer your questions regarding refstack? 16:49:04 so RefStack needs to include the types defined in market place is the recommendation? 16:49:21 correct 16:49:37 #agreed RefStack should include types as defined in the MarketPlace 16:50:03 catherine_d|1 any other questions? 16:50:03 #agreed RefStack should use self-registration for vendors with verification performed by the Foundation 16:50:17 Thank you all! 16:50:25 thanks catherine_d|1! 16:50:31 #topic midcycle planning 16:50:43 #link https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle 16:51:16 we started adding things, any other discussions that you think we should have during midcycle? 16:51:42 we wanted to discuss about using tests different than tempest yes/no 16:52:05 yes 16:54:18 thanks everyone for updating the ehterpad. we still have some time before the midcycle, so let me and markvoelker_ if you would like to discuss any of those topics sooner too 16:55:51 #topic open discussion 16:56:01 anything else anyone wants to add/disccuss? 16:56:53 if not, then we will end the meeting 3 minutes early :) 16:56:58 Can we add a section to the etherpad for the mid-cycle for any food requirements? 16:57:00 thanks everyone! 16:57:10 I will need to know for ordering lunches 16:57:11 brunssen i can send out a doodle for preferences! 16:57:15 like last time 16:57:16 Perfect 16:57:22 Thank you 16:57:24 and really appreciate IBM getting us lunches :) 16:57:26 thank you! 16:57:46 thanks everyone! 16:57:52 thank you 16:57:52 #endmeeting