18:02:35 <heckj> #startmeeting 18:02:36 <ayoung> NP 18:02:36 <openstack> Meeting started Tue Aug 21 18:02:35 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:50 <heckj> #topic: bugs and rc 18:03:06 <heckj> I spent some of this morning triaging bugs - have a few that I need to dig into a bit more 18:03:19 <ayoung> heckj, anything buring? 18:03:23 <ayoung> burning 18:03:38 <heckj> they're been a number of bugs filed about making auth_token more standalone - primary driver to it being that folks don't want to have to install all of keystone to get the auth_token pieces 18:04:03 <heckj> There's also a number of tracebacks and other quirks across various pieces - lots of recent bugs filed around using auth_token with swift 18:04:08 <ayoung> heckj, does it belong in openstackcommon? 18:04:23 <heckj> seems like that's a weak spot - maybe more so with documentation than anything else, but a weak spot none the less 18:04:47 <heckj> ayoung: At some point, yes - I don't think we're ready to shift it over there quite yet though. 18:04:50 <ayoung> heckj, well, I am partially to blame. PKI pulls in some deps 18:05:15 <heckj> It doesn't feel like that API is really stable at this point with the additions of what we're doing with the PKI token pieces, but I think we'll be able to shift that within another release 18:05:38 <ayoung> So could we somehow generate a library for it? 18:05:59 <dolphm> auth_token *should* be dependent on keystoneclient 18:06:01 <ayoung> keystone/common and keystone/middleware/auth_token 18:06:06 <heckj> a library, or a more limited package set of some form I think - I think that would solve most of the desires there 18:06:18 <dolphm> new home? keystoneclient.middleware.auth_token 18:06:35 <ayoung> dolphm, isn't keystone client the CLI? 18:06:48 <dolphm> ayoung: the CLI runs on top of a full python library 18:06:49 <heckj> if we're going to do that, I'd rather just move it into openstack-common 18:07:01 <dolphm> heckj: that's more intuitive 18:07:35 <heckj> On top of that, I think the clients need to be doing more to converge - the sort of inadvertant separation that occured over the past two release cycles is a bad place to be in 18:07:59 <heckj> dtroyer was starting something about an "openstack" client - don't know current state, but I'd like to support that explicitly 18:08:04 <ayoung> I'm not ready to surrender control of auth_token yet 18:08:12 <heckj> ayoung: that's my sense as well 18:08:35 <ayoung> I also think a CLI is a very different thing from a web integration piece 18:08:51 <dolphm> heckj: https://launchpad.net/python-openstackclient 18:08:51 <heckj> I think we'll also need to make some changes in auth_token when we get into supporting V3 API as well, so having it in a separate repo will be a pain point for making progress there 18:08:54 <ayoung> auth_token is really an extensioon to HTTProtocol 18:09:10 <ayoung> and could, in theory, be implemented in multiple languages 18:09:12 <heckj> #link https://launchpad.net/python-openstackclient 18:09:18 <heckj> (thanks dolphm ^^) 18:09:58 <dolphm> it would make sense to me that the python library be implemented in keystoneclient, and python-openstackclient uses that to implement the CLI (as the stated goal of openstackclient is a common shell across openstack) 18:10:15 <heckj> there's also a "security" bug reported, alhtough I don't think it's really a security issue 18:10:18 <heckj> sec for the link 18:10:19 <dolphm> heckj: it's not 18:10:26 <dolphm> heckj: bout to mark it invalid 18:10:51 <heckj> dolphm: +1 - it's a complaint that the API wasn't documented, but is intended 18:11:12 <dolphm> heckj: it's documented, just not where the user expected 18:11:21 <heckj> dolphm: didn't mean to throw that on your shoulders this morning - added you as subscriber so you could see it 18:11:58 <ayoung> why didn't https://review.openstack.org/#/c/10579/ get re smokestacked? 18:12:05 <dolphm> heckj: no worries 18:12:36 <heckj> ayoung: dunno there, maybe ping mtaylor or jeblair for insight?> 18:13:00 <mtaylor> aroo? 18:13:08 <mtaylor> heckj: we don't run smokestack 18:13:19 <heckj> Ah - well, you're not gunna help there then :-) 18:13:22 <heckj> mtaylor: who does? 18:13:25 <ayoung> mtaylor, is there an equivalent to recheck for smokestack? 18:13:36 <ayoung> for gerrit 18:14:29 <mtaylor> ayoung: nope. we have no control over it 18:14:32 <mtaylor> it's all dprince 18:14:38 <heckj> thanks 18:15:12 <heckj> we look like we're keeping up well on reviews 18:15:19 <ayoung> heckj, dolphm so that is the only thing I think I have in my pipeline that was submitted buy someone else that should go through 18:15:34 <heckj> which brings me to my next topic... 18:15:46 <heckj> #topic OCF scripts 18:15:50 <dolphm> mnewby: ? 18:16:00 <dolphm> ayoung: who's the someone else 18:16:03 <mnewby> dolphm: hi 18:16:07 <ayoung> apevec 18:16:18 * dolphm waves at mnewby -- didn't mean to summon you 18:16:19 <heckj> dolphm: the specific review that ayoung posted above 18:16:25 <dolphm> agh 18:16:27 <dolphm> ah* 18:16:54 <ayoung> dolphm, I mean that 10579 (submitted by apevec) is something I am shepherding through 18:17:01 <dolphm> OCF? 18:17:14 <ayoung> the only other change I have in my pipeline is mine for PKI...we can hold off on that until after OCF 18:17:14 <heckj> Yeah - ocf scripts 18:17:47 <ayoung> Isn't that Oracle Cluster File? no wait, that has an S 18:17:50 <ayoung> what is OCF? 18:17:51 <heckj> The OCF scripts are scripts that can be used with pacemaker to manage resources. I orginally thought it would be fine to include a set in our repo to make them easily available 18:18:15 <dolphm> something i'm not qualified to review, for sure 18:18:51 <heckj> bcwaldon brought up a really good point - his opinion is that anything in our repo should be fully supported - and we just don't have a lot of background or detail to be able to support, review, etc. OCF scripts - plus it's specific to actually ANOTHER project (pacemaker), so perhaps it wasn't actually appropriate to put into our repo 18:19:14 <ayoung> heckj, I concur with that analysis 18:19:31 <ayoung> I couldn't review it. I don't even know what OCF expands to. 18:19:35 <heckj> heh 18:19:41 <dolphm> satellite project? http://osdir.com/ml/openstack-cloud-computing/2012-02/msg00883.html 18:20:02 <heckj> dolphm: I think that's where it really belongs 18:20:25 <ayoung> I thought that was the general consensus from the IRC discussion 18:20:28 <dolphm> heckj: did anyone ever setup a directory of satellite projects? last i heard it would be through sourceforge? 18:20:33 <dolphm> but i've never seen one 18:20:38 <heckj> THere was some talk of a site that would list these things, including people's github repos and such, so that related projects could be found, but support/stability/etc attestation wasn't comign from core openstack projects 18:21:17 <heckj> there was a site planned called stackforge, but no end-user facing setup was created - mtaylor did some great work to expand where we can apply gerrit and CI tools, but that's where it ended 18:21:41 <heckj> I'm talking with some other folks to try and re-invigorate that effort to get something up and running 18:22:10 <heckj> sounds like solid consensus on that commit though, so I'll follow it up with email and relevant review comments 18:22:22 <heckj> #action heckj to follow up on moving OCF scripts elsewhere 18:22:27 <dolphm> cool 18:22:31 <mtaylor> ++ 18:22:36 <heckj> ayoung: you said you had another review item? 18:22:42 <heckj> #topic ayoungs review thing 18:22:42 <mtaylor> we have a stackforge github org that things can go in pretty easily 18:22:44 <mtaylor> and stuff 18:22:51 <heckj> mtaylor: ++ 18:22:56 <ayoung> heckj, PKI revocation. 18:22:57 <mtaylor> (and get hooked in to gerrit, should that be a useful thing) 18:23:11 <heckj> #topic PKI revocation 18:23:16 <heckj> take it away 18:23:31 <ayoung> I just reposted for review...asuming we get it through in the next day or so, doees it get merged over to the Folsom branch somehow, or are we going to cut RC1 from master? 18:23:50 <dolphm> master i believe 18:24:17 <heckj> ttx will cut RC1 from master 18:24:21 <ayoung> OK. So I am set with that...so here is what I found 18:24:29 <ayoung> the Vary Header gets set, but only for JSON 18:24:37 <ayoung> I was doing the Revocation list as straight text 18:24:42 <heckj> I haven't pestered mtaylor in detail with email about enabling a feature branch - which I thought we'd do for dolph's V3 api implementation work 18:24:52 <dolphm> ayoung: is there a reason why it's not / can't be in JSON? 18:24:57 <ayoung> but...it is a signed document, which means that it should be does via some standard or other, and sure enough 18:25:10 <ayoung> #link http://tools.ietf.org/html/rfc1847 18:25:22 <heckj> oh boy... 18:25:32 <ayoung> Now, I just found out today how to generate that format from openssl. It is not too bad 18:25:54 <ayoung> But...I am not going to do that, not yet 18:26:09 <ayoung> I am going to return the revocation list in a JSON document. 18:26:11 <dolphm> ayoung: does the client need to specify Accept: multipart/signed ? 18:26:13 <heckj> ayoung: just thinking that doing this right is more complex than I'd like for the timeframe we're in around release 18:26:19 <dolphm> need / should 18:26:48 <ayoung> dolphm, good question. I don't know. I don't think we/eventlet checks that.... 18:26:59 <dolphm> ayoung: keystone checks accept headers today 18:27:12 <ayoung> OK 18:27:30 <dolphm> ayoung: although i think application/json is assumed if one is not provided 18:27:47 <dolphm> otherwise application/xml is mildly supported 18:28:01 <dolphm> heckj: which reminds me of a v3 issue ^ actually 18:28:08 <ayoung> dolphm, yeah... 18:28:13 <heckj> yeah 18:28:20 <ayoung> I'd love it if we could hit keystone from a web browser directly 18:28:26 <ayoung> but that would mean to default to HTML 18:28:37 <dolphm> heckj: the {'entity': {...}} conversation we had about the entity containers ... 18:28:38 <ayoung> we can do that in V3...but it might break things on the landing page 18:28:43 <dolphm> heckj: sort of needed for easy xml support 18:28:50 <heckj> dolphm: AHHH!! 18:29:02 <heckj> dolphm: I wondered why we were doing that 18:29:30 <dolphm> {'this': {'attr': 'value'}} becomes <this attr="value" /> 18:29:47 <heckj> dolphm: yep, makes sense when you think about translation 18:30:06 <heckj> We're veering off from ayoung's topic though - 18:30:16 <ayoung> heckj, not necessarilty 18:30:20 <dolphm> and now back to our regularly scheduled program 18:30:24 <ayoung> I think we need to put a focus on proper rest for Grizzly 18:30:37 <heckj> Ok… wasn't sure what you needed, or if you got it with the checking vary-headers in the client 18:30:44 <ayoung> and that means we should support multiple content types. 18:31:03 <ayoung> So, I am not sure if the multipart/signed is right long term...I can investigate that 18:31:07 <heckj> ayoung: I agree, although I don't know how far down the HATEOS road I really want to go with this 18:31:53 <ayoung> heckj, this is how far I want to go 18:31:58 <heckj> ayoung: we can get into some hellashis complexity with using mime headers and such for versioning and request types - I would MUCH prefer to keep that simple 18:32:07 <ayoung> hit the landing page, use basic auth (or cert or kerberos in the future) 18:32:21 <ayoung> get apage with a link for everything that I can do 18:32:33 <dolphm> heckj: i'm definitely not a fan of using mime types of versions - ick 18:32:34 <ayoung> be able to do it all from a browser using a sparse HTML UI 18:33:10 <heckj> ayoung: doesn't that overlap pretty heavily with what's happening in horizon? 18:33:18 <ayoung> heckj, dolphm that is fine. Lets make the design decisions explicit 18:33:27 <ayoung> heckj, not really. This is for our use 18:33:33 <ayoung> and for the Keystone administrator 18:33:44 <ayoung> so they can diagnose with Horizon out of the picture 18:33:53 <ayoung> also for the end user scripting/integrating with Keystone 18:33:59 <dolphm> nothing is stopping a browser-side javascript-keystoneclient from existing, either 18:34:16 <ayoung> dolphm, well..not quite true 18:34:27 <ayoung> same origin policy is still in the way 18:34:37 <heckj> ayoung: I love it as a dev tool - not so sure about building up a user experience for keystone admins with it though... 18:34:57 <dolphm> right, but nothing is stopping someone from deploying keystone on the same domain as a JS client 18:34:57 <heckj> ayoung, dolphm : related: CORS support blueprint to enable that 18:35:00 <ayoung> heckj, Keystone is the rich tool. This is a debugging and testing tool 18:35:08 <ayoung> heckj, right....doesn't exist yet 18:35:09 <heckj> ayoung: yep - agreed 18:35:12 <ayoung> CORS that is 18:35:21 <heckj> yeah 18:36:19 <ayoung> But also, I think, if we were to build it that way, the Javascript client would consume pieces of it that don't yet exist: figuring out what data to put together for a form should be drive off a query from tjhe server 18:36:39 <ayoung> so...I'd like to make HTML a 1st class marshalling format for Grizzly 18:36:49 * dolphm runs 18:37:13 <ayoung> ayoung, catches up with dolphm trips him, and drags him back to the meeting 18:37:14 <heckj> uh, well - wow 18:37:27 <ayoung> heckj, simple, simple HTML: 18:37:45 * dolphm distracts ayoung with the xml middleware and makes another break for it 18:37:51 <ayoung> results come back in a <DL><DT><DD> ... form 18:38:56 <dolphm> ayoung: have you seen our application/xml support implementation? 18:39:05 <dolphm> ayoung: keystone.middleware.core.XmlBodyMiddleware 18:39:09 <ayoung> heckj, the same rules that go for XML should work for HTML, and then the whole thing should be browser friendly. Otherwise, we are not doing REST, we are just doing another SOAP 18:39:35 <heckj> ayoung: Oh sure… throw out the "I'll beat you with a brick of SOAP" card… 18:39:36 <ayoung> dolphm, right 18:40:07 <heckj> ayoung: WTF, let's give it a shot, see how it rolls. It'll be useful for us doing dev at least 18:40:18 <heckj> Somewhat side note: 18:40:26 <heckj> httplib2 broke my heart yesterday 18:40:35 <heckj> (novaclient and us… built on it) 18:40:54 <heckj> in the case of a timeout, with the current "release" of it, it automatically retries the connect... 18:41:14 <heckj> meaning that if you were running through a proxy, and the request timed out, it would double it... 18:41:37 <dolphm> ayoung: how do incoming HTML requests look? are they just multipart/form-data encoded? 18:41:40 <heckj> that's been made configurable in master of httplib2 development tree, but not yet released. 18:41:44 <dolphm> heckj: i saw your tweet lol 18:42:05 <dolphm> heckj: double the expected block time, i imagine? 18:42:34 <heckj> dolphm: we're repackaging httplib2 with the fix ourselves short term 18:42:43 <ayoung> dolphm, you mean from a browser? What kind of requests? POST or GET? 18:42:47 <dolphm> ayoung: POST 18:42:52 <dolphm> ayoung: and PATCH 18:43:03 <ayoung> haven't looked at patch yet. 18:43:23 <dolphm> ayoung: looks just like POST, except the resource isn't a collection 18:43:49 <ayoung> dolphm, I have to admit, I have been doing AJAX for so long that I am not sure. 18:43:55 <dolphm> ayoung: i believe the PUT operations in V3 don't require a request/response body 18:44:01 <ayoung> I had libraries managing it for me last project. 18:44:06 <heckj> ayoung, dolphm Any word from David Chadwick? Said he'd be on IRC, but I don't know what his nick would be... 18:44:17 <ayoung> he's on the wrong IRC server 18:44:28 <heckj> ah 18:44:30 <dolphm> heckj: (who's david chadwick?) 18:45:24 <heckj> dolphm: he's the guy that's been talking about federation and the use cases they need 18:45:29 <dolphm> ah cool 18:45:33 <ayoung> dolphm, wrote a Federated Keystone proof of concept 18:45:38 <heckj> d.w.chadwick@kent.ac.uk 18:45:44 <dolphm> oh yeah 18:45:46 <dolphm> i remember him 18:46:06 <ayoung> Sent him the URL for Freenode 18:46:21 <heckj> ayoung: thanks 18:46:31 <dolphm> attribute based authz? 18:46:53 <ayoung> dolphm, those links from last week? 18:47:06 <ayoung> http://etherpad.openstack.org/GrizzlyKeystoneSessions 18:47:08 <dolphm> ayoung: i'm thinking back to the essex conference, hadn't heard from him since 18:48:08 <ayoung> heckj, dolphm so the thing I wanted to make sure was that for the V3 API, we weren't assuming JSON by default. I think that will not allow the browsers to do HTML. 18:48:27 <ayoung> And instead, require an Accepts header. 18:48:51 <dolphm> ayoung: we can make it required, the clients i've seen are good about specifying it 18:48:54 <heckj> ayoung: that seems quite reasonable 18:49:08 <dolphm> ayoung: i know i'm lazy when it comes to curl/etc, but that's my fault :) 18:49:24 <ayoung> dolphm, its easy if you just cut/paste.... 18:49:50 <heckj> sounds like we should make some quick doc notes in our dev docs with relevant cut/paste usefulness :-) 18:50:00 <ayoung> yep 18:50:41 <ayoung> can we #action that? 18:50:55 <ayoung> or decision or whatnot? 18:51:08 <dolphm> require appropriate accept headers? 18:51:14 <ayoung> dolphm, yes,. that 18:51:23 <dolphm> and require appropriate content-type while we're at it? 18:52:00 <heckj> #action ayoung to scribble up some cut and paste URL examples with appropriate accept headers for dev docs 18:52:09 <dolphm> (we might already require appropriate content-type) 18:52:18 <heckj> #action: V3 API (all of us to implement) will require accept headers 18:52:33 <heckj> good ^ ? 18:53:21 <dolphm> so, i've got a giant chunk of v3 implemented 18:53:34 <dolphm> i haven't touched /tokens yet, though 18:53:39 <ayoung> good 18:53:48 <heckj> nice 18:54:04 <ayoung> dolphm, I can take a look once I've knocked out revocation. 18:54:32 <dolphm> ayoung: heckj: let me know when ya'll want to take a peek -- otherwise i'll keep chugging away offline 18:54:55 <ayoung> dolphm, OK...will do 18:55:21 <heckj> dolphm: I'll find out the feature branch idea that monty had and start that thread in email 18:55:21 <dolphm> ayoung: heckj: majorish change from my last review on policy -- i'm implementing a single router deployed to both :5000 and :35357 by default -- not making any distinction between API's whatsoever 18:55:35 <ayoung> dolphm, I like that! 18:55:58 <heckj> dolphm: I think that's a good way to go. 18:55:59 <ayoung> I would really really really like to be able to deploy on a single port. 18:56:01 <dolphm> ayoung: heckj: to compensate, i'd like to write some whitelist middleware for people that want it, which would only allow "public"-friendly calls to make it through ... but i wouldn't include it in keystone.conf.sample by default 18:56:26 <heckj> dolphm: seems reasonable - toss up a relevant blueprint on that, will you? 18:56:32 <dolphm> heckj: sure 18:56:47 <heckj> ayoung: related - IANA declined our request for another port # - so "35357" is our official port, and will stay that way 18:57:10 <dolphm> IMO, splitting up the API across multiple ports is a deployment concern, with MUCH better solutions on that side of the fence than what we're "enforcing" today 18:57:16 <ayoung> heckj, as well they should....but personally, I want to be able to deploy on 443.... 18:57:18 <dolphm> heckj: cool 18:57:24 <heckj> I think if we get policy implemented in our own API, we can and should drop this to a single port 18:57:35 <heckj> ayoung: word 18:58:08 <ayoung> OK, that is 15:00. We now turn into pumpkins 18:58:15 * dolphm runs from mtaylor 18:58:26 <ayoung> er..I guess the chat room turns into a pumpkin, and we turn back into mice. 18:58:26 <heckj> ayoung, dolphm - can one of you stand in for me in the release meeting today? 18:58:36 * mtaylor ties up dolphm and feeds him to jenkins 18:58:48 <heckj> '#endmeeting 18:58:53 <heckj> #endmeeting