19:00:52 #startmeeting ironic 19:00:53 Meeting started Mon Jul 22 19:00:52 2013 UTC. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:57 The meeting name has been set to 'ironic' 19:01:21 hi! 19:01:34 looks like we have a pretty full agenda today, which is great to see 19:01:37 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:02:21 lucasagomes: know if martyn is going to join us today? 19:02:25 wow we do 19:02:41 there are a lot of API things on the agenda, and i think his input would be useful 19:02:43 devananda, I don't know, lemme see if he's around 19:02:47 thanks 19:04:07 not really, he's not on the RedHat channels as well 19:04:18 hm, k 19:04:26 well, let's get started then 19:04:36 #topic to XML or not to XML 19:05:00 is there a compelling reason for XML support initially? 19:05:04 why use xml? 19:05:21 right, so should we support XML? as far as i know WSME works "OK" with xml responses 19:05:34 if I could vote I'd say -1 to xml 19:05:49 my initial thoughts are we don't need it 19:05:54 lucasagomes: :) 19:05:54 As I know some guys use XML in production. 19:06:06 martyntaylor, hey! 19:06:11 i don't know enough about client lib requirements to be sure, but i am keen on keeping things simple initially 19:06:28 romcheg: json is also very standard 19:06:35 lucasagomes: yo, sorry was a little late 19:06:51 so if we don't absolutely need xml in rev1, let's put it on the back burner. we will probably want to support it eventually 19:06:59 martyntaylor: hi! glad you could make it :) 19:07:05 devananda: +1 19:07:07 I agree with devananda 19:07:10 devananda, +1 19:07:13 o/ 19:07:35 devananda: +1 since the API is still evolving we may as well invest the effort in XML once its more stable 19:07:43 great 19:08:02 #agreed no XML support in rev1, to streamline our work on the JSON API 19:08:16 #topic PATCH request format 19:08:28 lucasagomes had found some good info on this last week... still have the links? 19:08:44 http://docs.openstack.org/api/openstack-image-service/2.0/content/update-an-image.html 19:08:49 http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 19:09:26 so, first, we need to agree with a patch format 19:09:31 and put it in our spec api 19:10:25 lucasagomes: I'd note for using the json patch format for 2 reasons. 19:10:36 #link http://docs.openstack.org/api/openstack-image-service/2.0/content/update-an-image.html 19:10:39 1. it's used else where in openstack, i.e. the example you just gabe 19:10:41 #link http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 19:10:52 (add #link sticks it in the .html meeting summary) 19:10:57 2. it's the closest thing to a standardised format 19:11:12 the negative, is that it's trickier to implement 19:11:29 once quesiton I have though, is that do we need PATCH in rev1 19:11:32 martyntaylor, I think there's a python lib which implents that already 19:11:44 https://github.com/stefankoegl/python-json-patch 19:12:08 https://pypi.python.org/pypi/jsonpatch/0.6 19:12:19 consumers of the ironic API will frequently be changing one or two parameters at a time 19:12:30 so PUT, even for sub resources, is less than ideal 19:13:20 devananda: yeah, I can certainly see its value. But it is just another (albeit more efficient way) to update a resource and we already support PUT 19:13:29 so patch instead of delete / readd 19:13:30 so either we require all API clients to GET then PUT a complete (sub)resource, or we allow PATCH. 19:13:59 I wonder whether effort is better spent implementing one update method and getting a v1 release of the API, then add in PUT or PATCH in necxt rev 19:14:23 martyntaylor: thats my question too 19:14:26 martyntaylor: what would that "one update method" be? 19:14:41 PUT and PATCH are both ways to update a resource 19:14:45 yes 19:14:50 oh 19:14:51 sorry 19:15:31 yeah so personally I would vote for PUT, since it is part of the HTTP spec 19:15:41 but I've no real object to PATCH 19:15:44 objection* 19:16:17 the use of PATCH will require education of new contributors, would it not? 19:16:29 so here's a problem with not having PATCH 19:16:42 problem with put is that it's more a "replace" than an "update" 19:16:55 my question is the how much would it delay rev1 release to work in patch 19:17:01 when an API client wants to change one attribute of driver_info, it will need to PUT the entire driver_info, including the password. every. single. time. 19:17:21 Why not use UPDATE which is the part of standard HTTP spec? 19:17:49 romcheg: aiui, that is PATCH. am I missing some part of the spec? 19:17:50 and also UPDATE is for "updating" not for replacing 19:18:37 devananda: yeah that is less than ideal. 19:18:55 romcheg: I'm not aware of UPDATE 19:19:07 Hmm 19:19:12 * NobodyCam takes a step back.. I don't think the question is will we support patch/update its do we need it for rev1 19:19:28 devananda: ^^? 19:19:44 NobodyCam: I think devananda question is if we are to support a single method of update, should it be PATCH or PUT 19:20:02 Looks like I was wrong all these years... 19:20:07 romcheg: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9 19:20:23 devananda: yup, already found that 19:20:44 PATCH isn't in the 1.1 spec either. it's a somewhat recent extension AIUI, but it's widely used now 19:20:54 yeah it's still an RFE 19:20:57 http://tools.ietf.org/html/rfc5789 19:21:30 so, NobodyCam put it well -- can rev1 function with only one method (put OR patch)? 19:21:35 i think we can't function without patch 19:21:46 I agree 19:21:52 because the requirement that all clients know all data all the time just to update any field is, well, not a reasonable requirement IMHO 19:22:06 we need to allow updating single fields 19:22:07 oh 19:22:19 I read that as we can* 19:22:24 :) 19:22:28 we also have a problem with the pecan/wsme object representation, the way we were doing PUT was to get the delta object, remove all the NULL fields (creating a delta object) and updating the documents with the fields that was filled 19:22:43 now it doesn't allow us set a field to NULL 19:22:52 the max you can do is to empty that field 19:23:01 lucasagomes: yes. this is part of the reason i haven't landed that patch of mine. i have not been happy with a few implementation / implications of it 19:23:04 like that 19:23:28 but that was a side effect of using PUT-like semantics, but hacked up to do updates instead of replace 19:24:03 devananda, yup, and supporting PATCH would fix that too 19:24:29 for structured objects (eg, node, port, chassis) pecan/wsme will provide us with NULL fields for any values not POST/PUT'ed 19:24:47 devananda: lucasagomes well we can catch that at the transformation layer 19:24:52 for the nested dicts (eg, driver_info, properties, extra) we just get the passed stuff. 19:25:04 so PUT needs to completely replace the existing dict 19:25:39 and we need PATCH to allow single-field updates of said dicts 19:26:24 we also need to be careful about race conditions with updates too 19:26:27 (there's another problem with wsme that I need to bring up later -- response code doesn't work today) 19:26:31 is it worth landing the current patch and a blueprint to refactor patch support 19:27:14 meeting 1/2 over and we are on topic #2? 19:27:18 eek 19:27:21 NobodyCam: thanks 19:27:31 let's table this and move on. 19:27:46 #action continue debate about PATCH support 19:27:47 right so... let's move on, we can talk about it another time at the #openstack-ironic 19:27:59 #topic RPC hooks 19:28:18 i think this is a no-brainer and I will land the patch importing Dan's work, unless anyone objects now :) 19:28:29 +! 19:28:33 1 even 19:28:38 +1 19:28:54 cool :) removed my -1 already 19:28:59 so +1 19:29:01 great 19:29:12 #agreed proceed with importing RPC serliazers 19:29:15 #topic testing 19:29:27 romcheg: i think you added this :) 19:29:31 Yup 19:29:40 and I would be thrilled for ironic to have more/better testing 19:30:05 We have folks here who landed the patch to OSLO that allows to test DB migrations. 19:30:20 indeed -- boris-42' teams work has been great there 19:30:29 I have asked yuriz to use it for Ironic 19:30:32 we have been in such a state of flux i think its been tuff to ramp up testing 19:30:34 ++ 19:30:41 We have a BP 19:30:54 link? 19:30:55 #link https://blueprints.launchpad.net/ironic/+spec/db-migration-tests 19:31:11 #action devananda to review bp: ironic/db-migration-tests 19:31:40 as for tempest // devstack integration, I think we're not quite there, but someone could start working on adding ironic to devstack 19:31:51 devanada that was hard) 19:31:52 As I know the patch for Ironic is ready. yuriz told me he will submit it as soon as devananda approves the BP 19:31:53 so that by the time we finish the API/RPC work, the devstack bits are in place 19:31:54 devananda ^ 19:32:45 romcheg, boris-42: do you guys have someone starting on the devstack integration? 19:33:07 No, currently no one's working on that 19:33:15 we also have NobodyCam working on diskimage-builder integration, though that won't lead to CI for a while (there are other issues blocking diskimage-builder CI right now) 19:33:32 romcheg: k. feel free to toss up a BP. we'll need it eventually :) 19:33:58 #action romcheg to post BP for devstack / tempest integration with ironic 19:34:26 moving on ... i'm going to skip the next few API items (which we sort of already talked about anyway). I'll come back to them if there's time 19:34:33 #topic copyright lines 19:34:42 #link https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers 19:34:53 everyone should (have) read that (already) 19:35:20 any questions? 19:35:36 devananda: are you using hacking 0.6 yet? 19:35:54 jog0: possibly not. want to post a patch? 19:36:05 devananda: it checks for copyright headers 19:36:15 cool 19:36:23 just makes sure apache2 header is correct and present 19:36:28 devananda: sure 19:36:43 #action jog0 to update us to use hacking 0.6 19:36:53 and check with you employeer 19:37:08 s/you/your/ 19:37:13 ah. yes. some employers have very specific policies for their employees 19:37:22 I'm sure there's an eclipse plugin for this hehe :D 19:37:53 any other comments on (c)? 19:39:04 k, moving on 19:39:09 #topic keystone auth 19:39:28 i'm good with ironic API being admin-only for now 19:39:46 romcheg got that working in a patch. thanks!! 19:39:47 devananda: how does that change with v3 keystone API? 19:40:02 romcheg: ^ ? 19:40:07 but keystone endpoints would be nice 19:40:09 jog0: we use authtoken_middleware 19:40:11 see justin santa barbara's ML thread 19:40:34 about domains 19:40:40 which allows us to not aware of changes in the keystone api 19:40:51 romcheg: how does it sort out domains? 19:41:57 jog0: Oh, I thought you were asking about checking the auth token. 19:43:05 As I know we do not depend on keystone api when we use python-keystoneclient. Not sure about some specific features. 19:43:32 romcheg: I am sort of .. disclaimer I don't know alot about v3 keystone API but domains change things I think 19:44:38 Since I have already started working on that part of Ironic, I can make a research on that. 19:44:43 ie ca none be an admin of a domain only? 19:44:49 can one * 19:44:49 perhaps one of you can raise this on the ML, so keystone folks can chime in? 19:45:06 devananda: http://lists.openstack.org/pipermail/openstack-dev/2013-July/012292.html 19:45:26 my goal is that, at least in ironic rev1, the ironic API be only accessible to a very restricted, privileged set of users 19:45:32 eg, "cloud admins" 19:46:55 devananda: +1 19:46:56 v3 only appeared in havana, didn't it? 19:46:56 #action romcheg to continue discussion about keystone v3 and domains 19:47:02 (for now) 19:47:03 romcheg: yes. new in havana 19:47:18 moving on cause we're short on time 19:47:24 ok 19:47:32 #topic PXE driver 19:47:47 GheRiver1: hi! any news on the pxe driver or glanceclient patches? 19:49:18 * devananda wonders if GheRiver1 is around ... 19:49:29 ok, we'll come back t that if he pops in 19:49:31 no news is good news? 19:49:36 #topic diskimage-builder 19:49:50 i've fallen a tad behind here 19:49:59 I should be back on track this week 19:50:30 there is a rabbit issue that seems to have popd up .. I need to look in to it more 19:50:55 short update is : not quite there yet. 19:52:09 k, thanks for the update 19:52:28 i skipped a bunch of the API related stuff, but there's one that i need to bring up 19:52:55 #topic WSME response object 19:53:21 basically, pecan 0.5b2 doesn't fully support the Response object 19:53:59 so we can't currently do things like "return 200 or 202, depending on XXX" 19:54:08 there's a bunch of #NOTEs in my patch about this 19:54:16 and I think it'll affect all of the API work for a little while 19:54:25 #topic open discussion 19:54:32 5 minutes left -- go :) 19:54:42 I have a question! 19:54:43 ^) 19:55:26 We have some todos to move the things related to eventlet to ironic.__init__ 19:55:26 I've another problem with the object representation in pecan/wsme... anyone knows a way to return only a subset of it? 19:56:11 lucasagomes: return different subsets from different methods? 19:56:12 I'm not too familiar with pbr. What's our problem with that? 19:56:18 lucasagomes: or have different methods return different things 19:56:25 devananda, for e.g 19:56:36 if we want to support something like this in our api 19:56:42 Currently we import eventlet in ironic.cmd.__init__ and ironic.test.__init-_ 19:56:43 GET ../chassis/1?fields=uuid,extra 19:56:53 it would return only some fields of that chassis 19:57:00 lucasagomes: oh. let's not do that :) 19:57:11 devananda, yea I know :) it was just an e.g 19:57:14 I have a question about transformation in pecan 19:57:21 well in particular in wsme 19:57:23 but it also works for the list of nodes for example 19:57:32 wehere I want to return only the UUID + link 19:57:56 lucasagomes: for that, i would create an API class that is UUID + link, and return a list of those 19:57:57 would the preferred approach be to use wsme complex types, templates or creating a pecan transformer objects 19:58:07 wsme complex types 19:58:11 and nested types where necessary 19:58:16 lucasagomes: like this open discussion (Meeting topic: ironic) 19:58:19 gah 19:58:20 devananda: thanks 19:58:25 i spoke (very briefly) with dhellmann last week and that was the conclusion 19:58:30 keystone endpoint-get --service ${service_name} | awk 'length($4)!=0 && $4 !="Value" { split($4,x,"/"); split(x[3],y,":"); print y[1] }' 19:58:59 romcheg: what's wrong with importing eventlent in .cmd.__init__ and .test.__init__? that seems fairly standard to me? 19:59:09 NobodyCam, what you mean? 19:59:12 I don't see a big value in parsing the output in our space 19:59:33 devananda, gotcha, yea creating another class with both attributes works, will do that then 19:59:34 let the user parse the output 20:00:00 vs requesting just name and link fields 20:00:01 devananda: it's actually more about gettext than about eventlet. 20:00:09 ok, we're out of time. thanks everyone, great meeting! 20:00:14 cheers gents 20:00:21 o/ 20:00:21 thanks 20:00:24 #endmeeting