19:01:10 #startmeeting ironic 19:01:11 Meeting started Mon Jul 29 19:01:10 2013 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:14 The meeting name has been set to 'ironic' 19:01:24 #chair NobodyCam 19:01:25 Current chairs: NobodyCam devananda 19:01:37 adding nobodycam to chair as I'm in Redding, tethered on my cell... 19:01:38 big aganda today 19:01:44 o/ 19:01:49 ~600ms ping, so i might drop 19:01:51 hey 19:02:02 o/ 19:02:12 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:02:14 agenda ^^ 19:02:59 so, let's run down the agenda :) 19:03:10 #topic testing 19:03:21 Oh, that's for me 19:03:25 romcheg: i think ... yep :) 19:03:28 some really nice patches around this this week 19:04:15 So I basically did some research and have some code that is powered by a set of dirty hacks but it deploys ironic to devstack 19:04:58 romcheg: sweet! think it'll be ready for a review soon? 19:05:09 I'm going to vanish it a little bit and publish in a day or two 19:05:10 (or even a draft so others can start to poke at it) 19:05:20 Yes, that will be a WIP 19:05:27 cool :) 19:05:34 awsome 19:05:45 also FYI for folks, yuriy add some more db tests 19:05:52 Currently it works exclusively on my VM so I cannot publish it :) 19:06:16 so migrations are now tested and any new db change must have tests added 19:06:26 great 19:07:06 NobodyCam: want to talk about your dib element now? it's related to testing ;) 19:07:21 I spoke to him today and he said he was going to add some opportunistic tests as well 19:07:31 I can 19:07:35 *to port those tests from nova 19:08:01 romcheg: i saw the pg/mysql opportunistic tests and merged it already :) 19:08:09 I have been using my ironic dib element to look into the stevedore issue 19:08:15 devananda: ah, great! 19:08:47 for those that don't know we get a error "IronicException: Failed to load driver fake." 19:09:02 how ironic 19:09:09 :-p 19:09:21 seems to be a stevedore issue 19:09:34 in testing we mox the object so it passes 19:10:29 so, romcheg, you may get the same error in devstack if you attempt to PATCH a node, since that will cause the conductor to load the node driver 19:10:57 here is the latest dump I have: http://paste.openstack.org/show/36uYgU0f5MhvbThAdmud/ 19:11:18 but the good news it rpc is working 19:11:23 devananda: I will keep that in mind thanks 19:12:05 #action NobodyCam to file a bug in ironic rconductor not able to load drivers 19:12:14 * devananda delegates :) 19:12:21 * NobodyCam will do 19:12:32 any other questions/concerns about testing? 19:12:55 k, moving on 19:12:59 #topic keystone 19:13:07 this was left open from last meeting 19:13:18 anyone have further insight into the question 19:13:19 There are some bad news 19:13:28 ? 19:13:31 Or at least not so good ones 19:14:03 I'm working on supporting keystone domains in ironic 19:14:30 However, I was not able to log in to keystone under a domain administrator to test the things. 19:15:06 I spoke to some guys who are familiar to keystone, but the problem is not solved yet. 19:15:16 romcheg: have you been in touch witht he keystone devs? 19:15:21 ah, ok 19:15:29 So the most of the code in ironic is ready. 19:15:55 when we have cross project dependencies like that 19:16:01 I will try to re-configure my setup tomorrow and try it again. 19:16:51 er, maybe i misread. are you waiting on keystone changes? 19:17:24 It's either a bug in keystone or misconfiguration of keystone in devstack 19:17:35 is there a keystone bug for the domian admin issue already 19:17:40 romcheg: are we the frist project to try using domains? 19:18:00 I still have not found that out yet 19:18:15 jog0: nova seems to use V3 api 19:18:23 do not know about domains 19:18:50 romcheg: so that may be the issue, we are first to use domains 19:19:28 romcheg: can you check for existing bug and if not file one? 19:19:44 NobodyCam: will do that. 19:20:12 :) 19:20:17 #action romcheg to file bug & investigate keystone domains 19:20:18 want a action line 19:20:21 oh 19:20:21 :p 19:20:22 :-p 19:20:38 moving on 19:20:41 #topic PXE drivr 19:20:42 ok 19:20:49 #topic PXE driver 19:21:05 GheRivero: hi! it looked like it was about to be merged, and then ... ? 19:21:14 it == the oslo image utils patch 19:21:25 link? 19:21:29 sec 19:21:46 s/oslo/python-g;aceclient 19:22:09 #link https://review.openstack.org/33327 19:22:38 flaper87 +2'd it and then someone else -1'd 19:23:49 also, I haven't gotten around to testing GheRivero's branch in a tripleo env yet 19:24:01 eddie does bring up some good points 19:24:29 that'll probably be the first thing i do when NobodyCam has the dib element all squared away (and i'm back from trips) 19:25:03 it seems like GheRivero isn't here, so unless anyone else has comments on either his glancecleint or pxe driver patches... let's move on 19:25:19 * devananda gives the room a minute 19:25:44 * NobodyCam notes that element sould work now for testing 19:26:16 https://github.com/NoBodyCam/ironic-element 19:26:36 NobodyCam: # link it pls :) 19:26:49 #link https://github.com/NoBodyCam/ironic-element 19:26:55 :-p 19:26:57 :) 19:27:00 k, moving on 19:27:03 #topic API 19:27:16 the big topic! and we still have 30 minutes left, hehe 19:27:38 lucasagomes: hi! you've been doing a lot on the api -- thanks! 19:27:46 :) 19:27:47 np 19:28:12 want to give an update of what's landed, what needs review, what's blocking you? 19:28:47 right 19:28:56 so self links to the resources landed last week 19:29:16 now I'm working in adding pagination to the collections 19:29:29 we still need patches to expose the nested resources 19:29:42 no blockers in the moment 19:29:53 but some decisions still needs to be made 19:30:01 for e.g the PATCH vs PUT thing 19:30:35 should we stick and use only one method to make updates at least for the first review? (using only PUT for e.g) 19:30:46 stick to one method to do update only* 19:31:11 was the argument against PATCH that the metalanguage would be complex to implement? 19:31:20 we have patch in who 19:31:20 *now 19:31:31 devananda, yea, and also we need to decide de format 19:31:34 NobodyCam: yes, but apparently I implemented it not according to spec 19:32:00 ahh 19:32:26 NobodyCam, http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 19:33:05 I think it's reasonable for our API to be consistent with other service APIs, at least in terms of how we implement basic commands 19:33:49 this is probably worth a mailing list thread to sort out 19:34:12 i can probably do taht tonight, unless someone else wants to 19:35:03 k 19:35:23 #action devananda to pose API PUT vs PATCh question on -dev ML 19:35:35 also, our spec is not aligned with the implementation 19:35:44 I will write a patch to update it soon 19:35:50 great, thanks! 19:36:13 what about parameter name rewrite / mapping? 19:36:20 eg, internal id == external uuid 19:36:31 do we really care about that? 19:36:47 or should we just updte the spec and expose uuid 19:37:32 woops, i typo'd -- spec says internal uuid == external id. I'm suggesting we just use uuid all the way through. 19:38:05 yea, nowadays you can use both, but the returns will always use uuids 19:38:19 devananda: +1 for consisteny 19:38:22 I'm happy changing it to use uuid only 19:38:56 ack. might as well work that in the spec change when you do it :) 19:39:08 cool 19:39:19 i have no update on the wsme version bump // status return codes issue 19:39:51 anyone have more API questions/comments? 19:40:00 yea it's a problem... we should talk to dhellman and see when will be the next wsme realease 19:40:16 * dhellmann is lurking 19:40:23 hi! 19:40:25 :D 19:40:25 hi! 19:40:26 hey 19:40:27 so, wsme 19:40:36 there are 2 things going on 19:41:04 first, some of the fixes that are included in trunk now only work with pecan, and Christophe wants some level of feature parity before doing a release 19:41:19 second, we are working out the details of moving wsme to stackforge (although that doesn't hold up the release) 19:41:44 stackforge++ 19:42:07 #link https://groups.google.com/forum/#!topic/python-wsme/TRLfq-GQBhg 19:42:15 that's the discussion about moving ahead with another release 19:43:16 hmm 19:43:33 does that link work for you guys, or is it somehow encoded for me? 19:43:37 looks weird 19:43:37 proper handling of status codes, both for errors and non-error-but-non-default is going to be important 19:43:41 link worked for me 19:43:43 cool 19:44:08 most of nova->ironic interaction will be in updating certain fields 19:44:17 * NobodyCam work for me 19:44:21 some will be immediate ERROR/SUCCESS responses 19:44:23 *works 19:44:27 some will yield 202 INPROGRESS 19:44:41 makes sense 19:45:04 and that doesn't sound like an exception 19:45:08 15 minutes 19:45:10 right 19:45:13 ok 19:45:27 christophe is looking for input on an API for that, so maybe you have some? 19:45:40 * dhellmann hasn't given that any special thought, yet 19:45:59 i hadn't either -- beyond playing with the Response obj enough to realize it didn't work :( 19:46:09 it seemed like a reasonable approach though 19:46:20 yeah, it seems like it ought to 19:46:21 response.obj = thing 19:46:26 response.status = int 19:46:31 return response 19:46:43 * dhellmann nods 19:47:01 I don't want to take up the whole meeting with debugging that. Maybe post to the WSME list and we can work it out there? 19:47:05 k, i'll reply to that thread (tonight) 19:47:10 :-) 19:47:17 #action devananda to post to WSME list re: Response objects 19:47:26 #topic open discussion 19:47:31 and for now, go ahead and send pull requests to the wsme hg repo 19:47:41 :) 19:47:44 there are some tricky bits to moving it that may make it take a little while 19:47:57 gotcha 19:48:09 mostly around the test configurations, so I don't want to just break them 19:48:17 if anyone wants to dig into fixing wsme's response object ... ^ :) 19:48:40 is it wsme's object, or working with the combination of pecan/wsme? 19:48:43 dhellmann: link? i actally haven't looked for wsme's upstream before 19:48:52 dunno - haven't dug into it 19:48:57 #link https://bitbucket.org/cdevienne/wsme/ 19:49:03 thanks 19:49:55 np 19:50:47 so how about some stevedore talk 19:51:35 ah! another question for dhellmann then ;) 19:51:44 from my poking we have a issue here https://github.com/openstack/ironic/blob/master/ironic/openstack/common/rpc/dispatcher.py#L129-178 19:52:01 oh? 19:52:22 so we've found that, outside of unit tests, stevedore has been failing to load our drivers for a little while 19:52:34 :-/ 19:52:49 what are the symptoms? 19:52:56 here is a really bad log 19:52:57 tracebacks? 19:52:57 http://paste.openstack.org/show/36uYgU0f5MhvbThAdmud/ 19:53:22 note any thing with cjk was hacked in by /me 19:54:07 stevedore should be logging an exception if it tries to import something and fails 19:54:14 NobodyCam: I think you'll find this also in the traceack 19:54:16 where 19:54:19 https://github.com/openstack/ironic/blob/master/ironic/conductor/resource_manager.py#L64 19:54:27 dhellmann: it's raising an exception, yes 19:54:35 ah, ok, so at least it's not eating the error 19:55:04 well, no, the error in that log is a key error from trying to use the driver after it should be loaded 19:55:07 NobodyCam: yea, that paste matches the resource_manager link i just pasted 19:55:13 so there should be a traceback earlier in the log based on https://github.com/dreamhost/stevedore/blob/master/stevedore/extension.py#L96 19:55:18 oooh 19:55:22 if you're not seeing that, then there's something wrong with the logging setup 19:55:30 or it's not even trying to load it 19:55:34 true 19:55:40 dhellmann: i (was?) doing on-demand loading 19:55:55 that the full conductor log 19:55:57 or thought i was :) 19:56:09 there is a api log 19:56:19 devananda: you may be 19:56:24 * dhellmann reads a bit 19:56:28 show the request sent and error racieved back 19:56:50 *shows 19:56:52 it's a https://github.com/dreamhost/stevedore/blob/master/stevedore/dispatch.py#L77 19:57:00 NameDispatchExtensionManager 19:57:03 devananda: what keys does the _driver_factory have? did it find anything? 19:57:08 o/ 19:57:28 hey GheRivero 19:57:55 dhellmann: I'm not sure its finding anything at all 19:58:02 dhellmann: i dont have a test in front of me... 19:58:13 devananda: to be clear, the manager is going to import the code when it is instantiated and invoke_on_load means it is going to "call" the thing it gets from load() at the same time 19:58:27 so the "on demand" bit is really just getting something out of a dictionary 19:58:55 jit... image tools almos merged. some positive core reviews +1 and a couple of small bits missing. To be done in the next hours. meanwhile, i'll update the image-tools ironic branch just in case 19:59:00 it will log what it finds at debug level (https://github.com/dreamhost/stevedore/blob/master/stevedore/extension.py#L84) 19:59:04 sounds like we need to dump NodeManager._driver_factory inside that try: block 19:59:07 yep 19:59:18 dhellmann: NodeManager is instantiated on demand :) 19:59:29 let's move to #openstack-ironic, our time here is up 19:59:35 thanks everyone!! 19:59:37 1 minute 19:59:39 :) 19:59:40 but the extension manager is a class attribute according to https://github.com/openstack/ironic/blob/master/ironic/conductor/resource_manager.py 19:59:49 which means it is instantiated when the class is read, on import 19:59:58 #endmeeting