16:00:48 #startmeeting defcore 16:00:49 Meeting started Wed Feb 17 16:00:48 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:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:54 The meeting name has been set to 'defcore' 16:00:59 o/ 16:01:01 o/ 16:01:04 o/ 16:01:05 o/ 16:01:14 #topic agenda 16:01:23 #link https://etherpad.openstack.org/p/DefCoreRing.12 16:01:32 o/ 16:02:01 If anyone has additional items for today, please note them in the etherpad. We'll be talking about RefStack in the latter part of the meeting since catherineD may be on a bus at the moment. =) 16:02:19 #topic MidCycle Reminder 16:02:40 Our midcycle is fast approaching (March 8-9 in Austin) 16:02:49 There's an etherpad started with agenda items here: 16:02:55 #link https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle 16:03:17 * catherineD yes on public bus 16:03:19 If there are additional items you want to discuss, please add them ASAP. We'd like to start nailing down the agenda and assigning timeslots. 16:03:48 It would also be helpful if you'd leave your name beside items you add so we know who to contact with questions. =) 16:04:00 +1! 16:04:19 I'd like to take a first pass at timeboxing by next week's meeting so everyone can see it and suggest changes. 16:05:02 Oh, also: if you are attending in person and haven't yet responded to the dietary restrictions Doodle, please do so right away. 16:05:04 #link http://doodle.com/poll/ewsiepmhv9p6r8e7 16:05:19 Any questions on the midcycle? 16:06:02 Ok, moving right along then... 16:06:10 #topic New Capabilities 16:06:41 o/ 16:06:50 For the 2016.01 Guideline we divvied up the task of identifying potential new Capabilities by project and had one or two folks play point for each. 16:07:15 I think that was extremely useful in getting things done, so I'd like to do it again. And it's that time in the cycle where we need to get cracking. =) 16:07:37 To that end, we need volunteers to tackle ID'ing potential new capabilities for each project. 16:07:52 (as well as potentially removing older ones that are no longer useful or have been deprecated) 16:08:21 I'd be happy to help with compute :) 16:08:24 Would a quick breakdown of what you're signing up for be helpful before I start calling for volunteers? =) 16:08:33 * gema nods 16:08:48 Ok, here's how it works: 16:09:34 Basically your task is to identify new Capabilities in the project that potentially meet DefCore's Criteria ( https://github.com/openstack/defcore/blob/master/doc/source/process/CoreCriteria.rst ) 16:10:28 Generally, you should talk with the PTL's/project committers to help pinpoint new capabiliteis 16:10:46 Operators and end-users can be helpful, as well as user surveys, etc. 16:11:16 Once you think you've identified Capabilities, you'll put them into a patch against https://github.com/openstack/defcore/blob/master/working_materials/scoring.txt 16:11:40 And we'll all discuss. We generally expect several iterations of patchsets, so don't feel like you have to nail it all on the first go-around 16:12:17 Make sense so far? 16:12:22 yep 16:13:00 Again, your job is really just to make a first pass at it...once the candidates are posted we'll all be able to suggest ones that we think probably don't cut it, or suggest additional ones. 16:13:37 If anyone has additional questions about the mechanics, just ping me on #openstack-defcore and I'll be happy to assist. 16:14:03 ok, I will try to do keystone 16:14:35 gema, dwalleck: great, thanks! Could you add your names to the etherpad please? 16:14:47 I took Neutron last time and am happy to do so again. 16:14:55 done 16:15:11 done 16:15:22 catherineD: you were talking with the Heat folks last time, can I coerce you into working on that again? =) 16:15:59 * markvoelker forgets that catherineD is still on a bus...ok, we'll come back to that 16:16:26 Thanks to those of you who've signed up--I'll send out a note to the ML soliciting additional signups this week. 16:16:52 #action markvoelker to send email soliciting signups for IDing new capabilities and giving a summary of the process 16:17:02 #action everyone sign up to help with capabilities 16:17:24 Anything further on IDing new capabilities? 16:17:29 markvoelker: by when do we need to have it? 16:18:03 gema: ideally if we could have a first pass before the midcycle that would be awesome. But we have about a mont. 16:18:10 s/mont/month/ 16:18:12 markvoelker: ack, will try 16:18:42 Any other questions? 16:19:03 i think it is still too early for ceilometer 16:19:52 just looking at the maturity of the project here: https://www.openstack.org/software/project-navigator/ 16:20:40 eglute_s: yeah, there's some debate about that (see last user survey which says it's about as widely deployed in prod as Swift). I lean that way too, but I'm inclined to have the discussion. 16:21:03 we use ceilometer with various degrees of success 16:21:10 not sure how a user would access it, though 16:21:26 Anything else on scoring for now? 16:21:38 +1 on the discussion, but the fact the maturity is 2, compared to Heat's 6 and Swift 16:21:42 's 7 16:22:06 i also agree with gema, not sure how it would be exposed to users 16:23:36 eglute_s: Perhaps the best way to handle this is for you take Ceilometer, and simply submit rationale for why you think it's not ready for inclusion yet? That way we can still have a nice open discussion on the patch. 16:23:53 sure 16:24:03 eglute_s: excellent 16:24:39 OK, anything else on this topic? 16:24:50 next :) 16:25:08 #topic Designated code sections 16:25:17 dwalleck can you speak to that? 16:25:36 eglute_s: sure 16:26:06 I've had a lot of questions internally at Rackspace about the designated code sections 16:26:40 They were somewhat confused by the fact that there are critical code sections that are listed, but marked "false" for required 16:27:07 I'm assuming this means that they aren't required, but it seems a bit contridictory 16:27:19 dwalleck: I think I can speak to that 16:27:35 There's also some concerns I'm hearing about the critical code sections being a bit too vague, but that's another topic :) 16:28:44 SO basically I think this dates back to early in DefCore's history when formats for this hadn't really been hammered out yet (frankly I'm not totally sure they have been yet =p) 16:29:01 The idea was to provide some additional clarity about things that were explicitly not required 16:29:24 So there were no questions about whether a thing (drivers, in the case you cited in the etherpad) was required or not 16:30:05 Sounds like that didn't exactly happen. =p But your interpretation is correct: if it's listed as not required, it's not required (explicitly, rather than implicitly). 16:30:11 Make sense? 16:30:27 Makes complete sense! 16:30:51 I don't think we have any issues, but I wanted to make sure my understanding was correct regardless 16:31:04 I had one question actually 16:31:12 jose-idar: sure, go ahead 16:31:15 api": { "description": "API section means actually the CODE that exposes the API, not just API-comparability", "designated": true, "comment": ""} 16:31:33 exactly what part of the code is that designating? 16:31:56 jose-idar can you link to the line? 16:31:56 So, a bit more history... 16:32:21 Early on there was a notion of whether something could be called OpenStack if it provided an alternate but fully compatible implementation 16:32:29 to be more general, how does defcore define the exact code that must be run? 16:32:35 The decision was reached that for things like drivers that are meant to be pluggable, that's fine 16:33:00 But for things like the API server, that's not kosher because those are not intended to be swappable by the community 16:33:23 * catherineD will work on Heat scoring 16:33:41 Hence the additional clarifier in the comment there that API-compatibility isn't all that's needed; the actual API server code is. 16:33:54 IIRC, the core of this is that participation in the codebase is what matures the project and the community, and that's something OpenStack as a whole values. 16:33:56 I guess what I'm asking is, where is the list that says "these are the approved .py's" 16:34:18 for any given project 16:34:59 jose-idar: it doesn't exist. =) We've not attempted to define it down to that level, partly because that's an ever-changing list. Rather, the intent was to give guidance and handle specific questions as they came in 16:36:41 that clears up the vagueness a little, thanks 16:37:20 Sure. Designated sections are indeed a bit of a grey area, so if folks have suggestions on how to make them clearer, we're happy to entertain them. 16:37:45 Anything else on this topic? 16:38:29 would it be worthwhile to add designated sections to midcycle discussions? 16:38:30 #topic Data privacy in RefStack 16:38:42 eglute_s Yes 16:38:53 whoops, changed topic just too soon I guess =) Sure, add it to the etherpad please 16:38:56 thanks purp, will do! 16:39:10 Added. 16:39:19 catherineD: are you available now, or should we tackled dwalleck's topic first? 16:39:36 * eglute_s thanks purp 16:39:37 yes let's discuss the RefStack topics 16:39:39 thx 16:39:49 The floor is yours madame. =) 16:40:26 So RefStack is implementing vendor registration .... and the users belong to the vendor 16:40:58 Let me discribe how users information got stored in RefStack 16:41:56 RefStack uses OpenStack OpenID for authentication ... 16:42:43 when a user log into RefStack , the request is send to OpenStack OpenID for authentication ... https://openstackid.org/ 16:43:25 fron the response from OpenID , RefStack saves the user full name , email and OpenID to RefStack DB 16:43:41 that is how a user is register to RefStack .. 16:43:52 catherineD: who are the users? 16:44:08 (as opposed to the vendor, I mean) 16:44:26 user is anyone who log into RefStack site and have an OpenStack ID 16:44:41 yeah but who do you expect is going to be doing that 16:44:46 Many users can be associated with one vendor, and users can move to different vendors 16:44:50 someone that belongs to the vendor org? 16:45:12 hogepodge: makes sense thanks, I was thinking about end users (the people running the apps on the clouds) 16:45:19 let's defer the vendor discussion a bit later ... I will come back to that 16:45:24 ok 16:46:14 so my first question is ... should RefStack provides a API to list the users in RefStack ... and this REST API can be called by anyone with or without an OpenStack ID? 16:46:59 that is anonymous user who go to the RefStack site and do not sign in 16:47:45 catherineD: I guess I'm not sure what the use case for that would be...e.g. why would we want that to be possible? 16:47:54 catherineD I'd expect that's an authenticated call. 16:47:54 I would think not 16:47:57 With privileged access, yes. But not anonymously or to all users. That's my inclination. 16:48:11 +1 to what hogepodge said 16:48:28 agreed, authenticated 16:48:31 +1 hodgepodge 16:48:39 also, in terms of priority, is this API/feature of high priority? i would not think so 16:48:46 markvoelker: I actually see no use case for anonumous user but just want to check ... 16:48:46 this sounds like a nice to have later 16:48:57 great .. 16:49:22 catherineD: Ok. I think we have consensus here that it's definitely not something we'd want to see done anonymously, and maybe only to privilleged users. 16:49:44 now even with an authenticated users ... now on the list of user what info should be returned .... 1) user name (for sure) 2) user email 3) user OpenID 16:50:05 markvoelker: would you please log the agreement ... Thanks! 16:50:06 catherineD: Is there a use case behind adding a "list RefStack users" API call? 16:50:07 #agreed No anonymous API for listing all users and their OpenStackID info 16:50:44 purp: yes.. list user API is what we are working on now ... 16:51:02 catherineD: I get that. What problem does it solve? 16:51:32 catherineD: purp: I guess I could see that being useful for Foundation staff. The average authenticated RefStack user...notsomuch. 16:51:35 I can see wanting to list results. I'm struggling for a case where I'd want to get the list of all RefStack users. 16:52:03 purp: yup... 16:52:18 * markvoelker notes we have 8 minutes remaining 16:52:41 * eglute_s agrees with purp 16:52:48 * catherineD could we continure this discussion in #openstack-defcore 16:53:01 For administrative tasks I can see it as useful, but for general users I'm concerned about privacy. We should protect identifying information as we can. 16:53:02 * catherineD since RefStack is kind of stuck right now 16:53:14 hogepodge +1 16:53:27 hogepodge: purp: +1 16:53:29 I'd say return the OpenStackID only, and require a lookup elsewhere. 16:53:33 * rockyg sneaksl into the back of the channe 16:53:56 hogepodge: +1. As a Foundation staffer who would likely be the target audience for such an API if I'm reckoning correctly: would you find it useful, or can do what you need to do without it? =) 16:54:08 I can control what's shown at OpenStackID (name, email, photo). I don't want to expose anything beyond what I've allowed there through any channel. 16:54:38 catherineD we can definitely continue this in defcore channel later as well 16:54:51 +1 for privacy 16:54:53 I think what I'm hearing is "we don't think we need this at all today, so backburner it until we find a case in which we do". Accurate? 16:54:54 markvoelker: it would be useful in matching up vendors with users and doing some analysis. I'm building a defcore results database and could see it somehow interacting with it. 16:54:57 catherineD: Can certainly continue in #openstack-defcore, though I have a hard stop at 9a PST. 16:55:05 eglute_s: thx for continuing the discussion 16:55:41 so it seems like foundation member can see the list of users ... 16:55:44 markvoelker: +1 16:55:51 dwalleck - we wont have time for your topics, wait until next week, mailing list discussion, openstack-defcore later, or all of the above? 16:55:58 and the infor can be name, email, OpenID 16:56:11 eglute_s: mailing list or next week is fine 16:56:19 thanks dwalleck 16:56:26 I'm still putting together some data around the topics I had 16:56:32 now for a vendor .... vendor will have a group of vendor users ...vendor should be able to list all users in the vendor 16:57:09 catherineD yes, that makes sense for a vendor to see what users they have. can they do it through UI now? 16:57:44 eglute_s: not yet .. .but it is the plan for Mitaka 16:58:02 ok 16:58:40 I think I get the guidedances on users (that is foundation can list all users in RefStack, vendor can list user in vendor) 16:58:59 +1 16:59:02 next topic vendor info 16:59:09 we are out of time... 16:59:16 move to defcore channel? 16:59:21 catherineD: I think I wouldn't even worry about foundation staffers listing all users at this point, hogepodge said he probably doesn't have a use for it at the moment so it could be tabled until later 16:59:26 thank you I won't take long .. 16:59:36 Yes, please: over to #openstack-defcore 16:59:40 Thanks everyone! 16:59:46 thanks markvoelker 16:59:50 #endmeeting