16:00:48 <markvoelker> #startmeeting defcore
16:00:49 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:54 <openstack> The meeting name has been set to 'defcore'
16:00:59 <eglute_s> o/
16:01:01 <markvoelker> o/
16:01:04 <dwalleck> o/
16:01:05 <gema> o/
16:01:14 <markvoelker> #topic agenda
16:01:23 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreRing.12
16:01:32 <catherineD> o/
16:02:01 <markvoelker> 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 <markvoelker> #topic MidCycle Reminder
16:02:40 <markvoelker> Our midcycle is fast approaching (March 8-9 in Austin)
16:02:49 <markvoelker> There's an etherpad started with agenda items here:
16:02:55 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle
16:03:17 * catherineD yes on public bus
16:03:19 <markvoelker> 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 <markvoelker> 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 <eglute_s> +1!
16:04:19 <markvoelker> 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 <markvoelker> 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 <markvoelker> #link http://doodle.com/poll/ewsiepmhv9p6r8e7
16:05:19 <markvoelker> Any questions on the midcycle?
16:06:02 <markvoelker> Ok, moving right along then...
16:06:10 <markvoelker> #topic New Capabilities
16:06:41 <purp> o/
16:06:50 <markvoelker> 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 <markvoelker> 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 <markvoelker> To that end, we need volunteers to tackle ID'ing potential new capabilities for each project.
16:07:52 <markvoelker> (as well as potentially removing older ones that are no longer useful or have been deprecated)
16:08:21 <dwalleck> I'd be happy to help with compute :)
16:08:24 <markvoelker> 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 <markvoelker> Ok, here's how it works:
16:09:34 <markvoelker> 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 <markvoelker> Generally, you should talk with the PTL's/project committers to help pinpoint new capabiliteis
16:10:46 <markvoelker> Operators and end-users can be helpful, as well as user surveys, etc.
16:11:16 <markvoelker> 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 <markvoelker> 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 <markvoelker> Make sense so far?
16:12:22 <gema> yep
16:13:00 <markvoelker> 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 <markvoelker> If anyone has additional questions about the mechanics, just ping me on #openstack-defcore and I'll be happy to assist.
16:14:03 <gema> ok, I will try to do keystone
16:14:35 <markvoelker> gema, dwalleck: great, thanks!  Could you add your names to the etherpad please?
16:14:47 <markvoelker> I took Neutron last time and am happy to do so again.
16:14:55 <dwalleck> done
16:15:11 <gema> done
16:15:22 <markvoelker> 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 <markvoelker> 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 <markvoelker> #action markvoelker to send email soliciting signups for IDing new capabilities and giving a summary of the process
16:17:02 <markvoelker> #action everyone sign up to help with capabilities
16:17:24 <markvoelker> Anything further on IDing new capabilities?
16:17:29 <gema> markvoelker: by when do we need to have it?
16:18:03 <markvoelker> 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 <markvoelker> s/mont/month/
16:18:12 <gema> markvoelker: ack, will try
16:18:42 <markvoelker> Any other questions?
16:19:03 <eglute_s> i think it is still too early for ceilometer
16:19:52 <eglute_s> just looking at the maturity of the project here: https://www.openstack.org/software/project-navigator/
16:20:40 <markvoelker> 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 <gema> we use ceilometer with various degrees of success
16:21:10 <gema> not sure how a user would access it, though
16:21:26 <markvoelker> Anything else on scoring for now?
16:21:38 <eglute_s> +1 on the discussion, but the fact the maturity is 2, compared to Heat's 6 and Swift
16:21:42 <eglute_s> 's 7
16:22:06 <eglute_s> i also agree with gema, not sure how it would be exposed to users
16:23:36 <markvoelker> 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 <eglute_s> sure
16:24:03 <markvoelker> eglute_s: excellent
16:24:39 <markvoelker> OK, anything else on this topic?
16:24:50 <eglute_s> next :)
16:25:08 <markvoelker> #topic Designated code sections
16:25:17 <eglute_s> dwalleck can you speak to that?
16:25:36 <dwalleck> eglute_s: sure
16:26:06 <dwalleck> I've had a lot of questions internally at Rackspace about the designated code sections
16:26:40 <dwalleck> They were somewhat confused by the fact that there are critical code sections that are listed, but marked "false" for required
16:27:07 <dwalleck> I'm assuming this means that they aren't required, but it seems a bit contridictory
16:27:19 <markvoelker> dwalleck: I think I can speak to that
16:27:35 <dwalleck> 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 <markvoelker> 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 <markvoelker> The idea was to provide some additional clarity about things that were explicitly not required
16:29:24 <markvoelker> 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 <markvoelker> 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 <markvoelker> Make sense?
16:30:27 <dwalleck> Makes complete sense!
16:30:51 <dwalleck> I don't think we have any issues, but I wanted to make sure my understanding was correct regardless
16:31:04 <jose-idar> I had one question actually
16:31:12 <markvoelker> jose-idar: sure, go ahead
16:31:15 <jose-idar> api": { "description": "API section means actually the CODE that exposes the API, not just API-comparability", "designated": true, "comment": ""}
16:31:33 <jose-idar> exactly what part of the code is that designating?
16:31:56 <eglute_s> jose-idar can you link to the line?
16:31:56 <markvoelker> So, a bit more history...
16:32:21 <markvoelker> 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 <jose-idar> to be more general, how does defcore define the exact code that must be run?
16:32:35 <markvoelker> The decision was reached that for things like drivers that are meant to be pluggable, that's fine
16:33:00 <markvoelker> 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 <markvoelker> 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 <purp> 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 <jose-idar> I guess what I'm asking is, where is the list that says  "these are the approved .py's"
16:34:18 <jose-idar> for any given project
16:34:59 <markvoelker> 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 <jose-idar> that clears up the vagueness a little, thanks
16:37:20 <markvoelker> 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 <markvoelker> Anything else on this topic?
16:38:29 <eglute_s> would it be worthwhile to add designated sections to midcycle discussions?
16:38:30 <markvoelker> #topic Data privacy in RefStack
16:38:42 <purp> eglute_s Yes
16:38:53 <markvoelker> whoops, changed topic just too soon I guess =)  Sure, add it to the etherpad please
16:38:56 <eglute_s> thanks purp, will do!
16:39:10 <purp> Added.
16:39:19 <markvoelker> catherineD: are you available now, or should we tackled dwalleck's topic first?
16:39:36 * eglute_s thanks purp
16:39:37 <catherineD> yes let's discuss the RefStack topics
16:39:39 <catherineD> thx
16:39:49 <markvoelker> The floor is yours madame. =)
16:40:26 <catherineD> So RefStack is implementing vendor registration .... and the users belong to the vendor
16:40:58 <catherineD> Let me discribe how users information got stored in RefStack
16:41:56 <catherineD> RefStack uses OpenStack OpenID for authentication ...
16:42:43 <catherineD> when a user log into RefStack , the request is send to OpenStack OpenID for authentication ... https://openstackid.org/
16:43:25 <catherineD> fron the response from OpenID , RefStack saves the user full name , email and OpenID to RefStack DB
16:43:41 <catherineD> that is how a user is register to RefStack ..
16:43:52 <gema> catherineD: who are the users?
16:44:08 <gema> (as opposed to the vendor, I mean)
16:44:26 <catherineD> user is anyone who log into RefStack site and have an OpenStack ID
16:44:41 <gema> yeah but who do you expect is going to be doing that
16:44:46 <hogepodge> Many users can be associated with one vendor, and users can move to different vendors
16:44:50 <gema> someone that belongs to the vendor org?
16:45:12 <gema> hogepodge: makes sense thanks, I was thinking about end users (the people running the apps on the clouds)
16:45:19 <catherineD> let's defer the vendor discussion a bit later ... I will come back to that
16:45:24 <gema> ok
16:46:14 <catherineD> 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 <catherineD> that is anonymous user who go to the RefStack site and do not sign in
16:47:45 <markvoelker> 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 <purp> catherineD I'd expect that's an authenticated call.
16:47:54 <eglute_s> I would think not
16:47:57 <hogepodge> With privileged access, yes. But not anonymously or to all users. That's my inclination.
16:48:11 <eglute_s> +1 to what hogepodge said
16:48:28 <gema> agreed, authenticated
16:48:31 <SammyD> +1 hodgepodge
16:48:39 <eglute_s> also, in terms of priority, is this API/feature of high priority? i would not think so
16:48:46 <catherineD> markvoelker: I actually see no use case for anonumous user but just want to check ...
16:48:46 <eglute_s> this sounds like a nice to have later
16:48:57 <catherineD> great ..
16:49:22 <markvoelker> 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 <catherineD> 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 <catherineD> markvoelker: would you please log the agreement ... Thanks!
16:50:06 <purp> catherineD: Is there a use case behind adding a "list RefStack users" API call?
16:50:07 <markvoelker> #agreed No anonymous API for listing all users and their OpenStackID info
16:50:44 <catherineD> purp: yes.. list user  API is what we are working on now ...
16:51:02 <purp> catherineD: I get that. What problem does it solve?
16:51:32 <markvoelker> catherineD: purp: I guess I could see that being useful for Foundation staff.  The average authenticated RefStack user...notsomuch.
16:51:35 <purp> 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 <catherineD> 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 <hogepodge> 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 <purp> hogepodge +1
16:53:27 <catherineD> hogepodge: purp: +1
16:53:29 <purp> 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 <markvoelker> 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 <purp> 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 <eglute_s> catherineD we can definitely continue this in defcore channel later as well
16:54:51 <eglute_s> +1 for privacy
16:54:53 <markvoelker> 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 <hogepodge> 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 <purp> catherineD: Can certainly continue in #openstack-defcore, though I have a hard stop at 9a PST.
16:55:05 <catherineD> eglute_s: thx for continuing the discussion
16:55:41 <catherineD> so it seems like foundation member can see the list of users ...
16:55:44 <hogepodge> markvoelker: +1
16:55:51 <eglute_s> 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 <catherineD> and the infor can be name, email, OpenID
16:56:11 <dwalleck> eglute_s: mailing list or next week is fine
16:56:19 <eglute_s> thanks dwalleck
16:56:26 <dwalleck> I'm still putting together some data around the topics I had
16:56:32 <catherineD> 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 <eglute_s> catherineD yes, that makes sense for a vendor to see what users they have. can they do it through UI now?
16:57:44 <catherineD> eglute_s: not yet .. .but it is the plan for Mitaka
16:58:02 <eglute_s> ok
16:58:40 <catherineD> 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 <eglute_s> +1
16:59:02 <catherineD> next topic vendor info
16:59:09 <eglute_s> we are out of time...
16:59:16 <eglute_s> move to defcore channel?
16:59:21 <markvoelker> 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 <catherineD> thank you I won't take long ..
16:59:36 <markvoelker> Yes, please: over to #openstack-defcore
16:59:40 <markvoelker> Thanks everyone!
16:59:46 <eglute_s> thanks markvoelker
16:59:50 <markvoelker> #endmeeting