18:05:14 <heckj> #startmeeting
18:05:15 <openstack> Meeting started Tue Apr 24 18:05:14 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:05:37 <heckj> welcome back from the summit!
18:05:43 <jsavak> :)
18:05:46 <heckj> #topic - future work
18:06:08 <heckj> We had some great conversations at the summit, and most (but not all) are reflected in blueprints
18:06:49 <heckj> With Folsom, I'm aiming to move any "need to do this" into blueprints (away from "bugs). So if you have elements you'd like to do, please add them in as blueprints over the next few days
18:07:20 <jsavak> what's the approval process for the bp?
18:08:11 <dolphm__> Bug heckj?
18:08:13 <heckj> jsavak: right now, create it as "new" and assign it to yourself. When we're agreed on method implementation, someone on the core team (me, termie, etc) will change the BP to approved
18:08:30 <jsavak> okie.
18:08:45 <heckj> You *do not* need to wait for a BP to be approved to start work
18:09:08 <heckj> submitting a code review is a perfectly acceptable (and actually quite effective) way to get an implementation conversation started.
18:09:21 <heckj> The blueprint should ideally outline "success" criteria more than anything else.
18:11:08 <jsavak> ok, cool, thx
18:11:25 <gyee> heckj, I am changing the role apis to add the service_id back in there
18:12:13 <heckj> #topic: next api
18:12:47 <gyee> role apis
18:12:49 <heckj> related to gyee - with the feedback we gathered, I'll be working with termie to consolidate the API into a next revision and get that up as a document proposal over the next few weeks.
18:12:55 <gyee> I've add the service_id back in there
18:12:57 <gyee> added
18:13:22 <heckj> will be looking forward to feedback from y'all on that document when we get it live
18:13:44 <heckj> In the meantime, there's an open discussion on modeling the endpoints on the mailing list - please contribute to the conversation there.
18:14:04 <dolphm> heckj: etherpad or anything for api stuff?
18:14:11 <gyee> heckj, you are proposing that we move service_type and region to attributes?
18:14:40 <heckj> doplhm: I was going to follow Jay's pattern and make a google doc for feedback - easier to track (for me) on feedback than etherpad
18:15:22 <heckj> gyee: I'm promising to get an API up for feedback - I'm looking for more conversation related to relevant attributes and how to think about them on the mailing list.
18:15:49 <heckj> gyee: I'm not sure what "region" means to folks - so it's hard to assert anything concrete there
18:16:04 <dolphm> heckj: +1
18:16:07 <heckj> gyee: and I'm not sure entirely which field you're referring to re: service_type
18:18:08 <heckj> gyee: did that answer your question?
18:18:20 <gyee> there's a service_type field in the endpoint templates right?
18:18:28 <dolphm> <service name="My Nova" type="compute" region="north" /><endpoint ... /><endpoint ... /></service>
18:18:39 <heckj> the one that contains "image", "compute" - yeah
18:19:02 <gyee> so we are moving that one to attributes? I wasn't clear on that
18:19:30 <heckj> gyee: I'm more asking what people think about representing the resources over trying to assert a specific proposal at this point.
18:20:03 <heckj> gyee: I'm not 100% certain what we're modelling and what it's inteded to represent, so I'm asking for people (you, dolph, etc - anyone who cares) to assert  opinions there
18:21:05 <gyee> sure, I'll spend some time catching up on on the emails
18:21:13 <heckj> gyee: cool, thank you
18:21:28 <heckj> (the keystone stuff has been light - mostly it's been hyperactive discussions on metrics and billing data)
18:21:42 <heckj> #topics issue and open questions
18:21:52 <heckj> General discussion time - I didn't have anything else formal
18:22:10 <rafaduran> I have some patchs that need review
18:22:45 <rafaduran> https://review.openstack.org/#/c/6447/ https://review.openstack.org/#/c/6448/ https://review.openstack.org/#/c/6425/
18:23:28 <rafaduran> I don't what's the better way to get attention to them
18:23:35 <rafaduran> I don't know
18:23:40 <heckj> you just did :-)
18:24:24 <heckj> rafaduran: you can also request specific reviewers (heckj, termie, dolphm, bcwaldon, etc) when you go to the review page. It's a good way to "poke" someone to review your code
18:24:54 <dolphm_> rafaduran: as i said in the reviews, this functionality is already covered by the core api spec, and your implementation doesn't match that
18:24:55 <rafaduran> heckj: thx, I will do that way next time
18:25:08 <dolphm_> rafaduran: those features were present pre-redux, and i'd be happy to see them return
18:25:15 <dolphm_> rafaduran: but not under a whole new api
18:25:24 <rafaduran> dolphm_:I've sent new patches
18:25:24 <dolphm_> rafaduran: unless we're changing the *whole* api :)
18:25:34 <cloudfly> i was going to post a question about preventing mitm attacks on keystone to the list  =/
18:25:44 <cloudfly> i hope it does not get large
18:25:53 <heckj> cloudfly: give it a shot - hard to tell :-)
18:26:03 <dolphm_> rafaduran: ah, i'll take another look then - totally didn't notice
18:26:37 <rafaduran> dolphm_: ok, thx for your attention
18:30:41 <heckj> dolphm: My thought is to aiming for a fairly heavy revision, consolidating token more than really changing it, and bringing many of the extensions into core
18:31:03 <heckj> and adding the CRUD elements with the expectation that backends may return "not implemented" as a valid response
18:31:07 <dolphm_> heckj: i'm all for that, generally speaking
18:31:29 <heckj> Other questions or issues? ideas? etc?
18:31:32 <dolphm_> heckj: and i'm all for simplifying the service catalog
18:35:27 <gyee> by simplifying you also mean maintaining backward compatibility as well right?
18:36:27 <jsavak> or at least have it under v3.0
18:36:43 <gyee> open season for v3.0 :)
18:36:57 <dolphm_> or we could skip to 4.0
18:37:08 <dolphm_> or more appropriately, v4
18:40:03 <heckj> gyee: maintaining backward compatibility will be keeping the same versioned API - my proposal will be to make a new versioned API for this next round
18:40:13 <heckj> And being able to run both of them together
18:40:28 <gyee> nice
18:42:19 <heckj> Okay - I think that's it for today's meeting
18:42:25 <heckj> #endmeeting