19:01:06 #startmeeting ironic 19:01:07 Meeting started Mon Sep 30 19:01:06 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:12 The meeting name has been set to 'ironic' 19:01:18 hi all! 19:01:21 o/ 19:01:24 Good evening! 19:01:31 hi 19:01:34 hi 19:01:39 Hi 19:01:50 I believe NobodyCam is on the road right now, but he might pop in to join us 19:02:09 I've done a brief update to the agenda, added some notes -- https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 19:02:35 and I'll try to be brief, so we have time for any discussions that folks want to have :) 19:02:49 #topic CFP for summit 19:03:01 #link http://summit.openstack.org/cfp/topic/7 19:03:08 so far we have 6 proposed talks 19:03:10 hi 19:03:39 some of them are geared towards long-term goals 19:03:40 which is great 19:04:00 and I want to encourage more folks to submit session ideas 19:04:24 but also, we need to focus on getting to the first functional release in the Icehouse cycle 19:04:27 *early in the ... 19:04:42 so I've set aside one session for us to talk about that: http://summit.openstack.org/cfp/details/139 19:04:59 any questions on hong kong? 19:06:11 ok, moving on 19:06:15 #topic testing 19:06:22 I have a few updates here 19:06:42 great 19:07:06 i have only one -- that I've been testing lucasagomes' python-ironicclient in conunction with NobodyCam's undercloud image 19:07:10 and they work well together :) 19:07:13 I have written API tempest tests that cover simple API usage: CRUD operations on the resources 19:07:31 Several gates still fail but I expect to fix that tommorow 19:07:49 awesome! have a link handy? 19:07:56 :) I've been testing the ironicclient with romcheg's devstack and it working fine as well! 19:07:59 I think it's the time to create a non-voting job for Infra? 19:08:23 devananda: I do have a link but the latest changes are not there 19:08:25 sounds good to me. mordred ? ^ 19:08:26 Gimme a sec 19:08:43 #link https://review.openstack.org/#/c/48109/ 19:08:56 There are just a few CREATE tests 19:09:06 what did I do? 19:09:18 I just test everything locally — faster 19:09:42 yes! I believe non-voting jobs in Infra are a great idea! 19:09:52 :) 19:10:03 then you can create an # action for me 19:10:49 #action romcheg to propose a non-gating job to -infra 19:11:05 #action romcheg to propose a non-voting job to -infra 19:11:34 Two actions is always better than one :) 19:11:47 romcheg: that's really good news :) thanks for working on all the testing side of things! 19:11:48 hehe 19:12:11 anything else on testing before we move on? 19:12:19 Also devstack now exposes a different endpoint 19:12:35 Might be essential for lucasagomes who is testing the client 19:13:04 romcheg: ironic-api service is registered as "baremetal" service type, yes? 19:13:08 romcheg, I'll take a look... so you sorted out the thing about having to explicit put /v1 on the path? 19:13:09 Exactly 19:13:34 lucasagomes: Yes, I got another +10 to diplomacy :) 19:13:42 :) 19:13:43 :) 19:13:43 sweet 19:14:11 #topic python-ironicclient 19:14:17 so we've already touiched on this a few times :) 19:14:29 basically, lucasagomes rocks,a nd we have a python client in progress 19:14:51 lucasagomes: I think I can add the client to devstack, right? 19:15:03 yes! 19:15:07 cool 19:15:08 i would think so. it's working fine for me locally! 19:15:13 please, action me more :) 19:15:17 ironic node-list ... ironic node-create ... etc .. 19:15:27 #action romcheg to add python-ironicclient to devstack install scripts 19:15:41 there's a patch upstream implementing update on resources 19:15:52 so the basic commands are almost all there 19:15:57 there = upstream 19:16:00 lucasagomes: yep. i saw but haven't reviewed yet. will try to find time today, bu tmight not get to it 19:16:10 np :) 19:16:45 we're approaching the state of "must land change in A before we can test change in B" 19:17:05 ie, dependencies between python-ironicclient and devstack/tempest's ability to test ironic 19:18:13 also, vendor_passthru landed in trunk 19:18:25 yea, getting things working soon will give us a lot of time to polish Ironic and release a very good v1 on icehouse 19:18:49 IMHO, we should expose that in the API client, but not necessarily in teh CLI itself. 19:19:13 +1 19:19:25 if vendors want to have a client then can create their own using the lib 19:19:37 and then they can expose their custom functions 19:19:42 lucasagomes: yep. the sooner we get all the bits together and into -infra, the more time we have to be sure it all works before icehouse 19:19:49 lucasagomes: exactly 19:19:58 but my new small test on nodes API side failed, Pecan broken again 19:20:37 https://bugs.launchpad.net/pecan/+bug/1233258 19:20:39 Launchpad bug 1233258 in pecan "'_default' handler does not work" [Undecided,New] 19:21:00 dhellmann: another pecan issue with latest release ^^ 19:21:10 did that used to work? 19:22:02 Yes, existing code broken 19:22:09 dhellmann, yes, that was how we were implementing our vendor_passthru resource 19:22:19 what is that? 19:22:51 ok, I think I'm caught up with the code 19:23:18 I probably would have had the vendor provide a controller implementation and plug it into the main controller tree explicitly, but if this was working we should make it work again 19:24:04 it's a resource that allows vendors to extend our API in order to expose some custom functionality 19:24:06 dhellmann: this is implemented so that teh vendor doesn' tneed to patch the API, and so the API doesn't need to load plugins 19:24:28 dhellmann: vendor can provide a plugin to the conductor node, and our existing API just forwards special requests to their driver plugin 19:24:29 why is having the api not load plugins a design goal? 19:25:35 dhellmann: separate functionality for what is core / common to all drivers vs. what is an extension to the vendor's driver 19:26:09 #link http://docs.openstack.org/developer/ironic/dev/architecture.html#Drivers 19:26:31 this may be something to discuss in person with less of a lag, but it feels like the wrong approach off the top of my head 19:26:43 dhellmann: "not load plugins" may be too broad of a statement. the API does load plugins. but for a vendor to extend Ironic's hardware support, they don't need to write two plugins. just one. 19:26:45 I'll have Ryan look at the bug 19:26:57 dhellmann: sure. i'm happy to talk about the arch at ODS :) 19:27:15 dhellmann: thanks! I tried to reach him but not on IRC 19:27:33 yeah, we're all heads-down trying to get some internal stuff done 19:28:24 yuriyz: do you think you can work around this for now? 19:29:16 only if pass 'method' in body, not in url 19:29:50 hrm, k. let's talk about that after the meeting / on the ML 19:29:58 any other API questions/issues? 19:30:19 if not, we're up to FFT and open discussion 19:30:39 #topic open discussion 19:32:14 don't all talk at once :p 19:32:21 cue crickets 19:32:34 dkehn: hi! 19:32:38 devananda, hi 19:32:48 dkehn: how about the neutron integration in nova-baremetal? 19:33:25 on hold today, it appears that they have opened up the neutron and I've got del to complete 19:33:29 dkehn: did that affect the pxe sub-driver at all, or just the nova/virt/baremetal/driver.py ? 19:33:51 haven't really started on the refactoring stuff 19:34:02 did what 19:34:08 maybe I should ask 19:34:12 ah, somehow i thought a bunch of that was proposed last week 19:34:37 hmm, I only saw the lifeless stuff which was more of a question 19:34:47 the +5 thing 19:35:00 k 19:35:21 also got new hardware which I'm trying to get it back there were I was when I left the old hardware 19:35:44 well, if the nova-baremetal->neutron integration affects pxe.py, that should be fairly easy to port to ironic/drivers/modules/pxe.py 19:36:00 Its pretty much there, but spent the morning screwing around with a new neutron env on the new hardware, nothing ever goes as planned 19:36:00 devananda: http://summit.openstack.org/cfp/details/154 19:36:31 and if the neutron integration affects baremetal/driver.py, I'd like to know as i'll probably be writing the nova-ironic driver in the next month or so 19:36:42 devananda, ok 19:36:59 lucasagomes: that session also interesting for you ^ 19:36:59 dhellmann, sweet! 19:37:07 yup 19:37:20 dhellmann: thanks for pointing it out :) 19:38:40 devananda, https://review.openstack.org/#/c/45589/ is probably where its going 19:38:43 idk much about the neutron integration, but might have to change something on pxe no? so it can inform which macaddress are allowed to get a dhcp request? 19:39:24 lucasagomes: possibly 19:39:42 it's sort of a question of, does ironic tell neutron stuff? or does nova tell neutron that stuff? 19:40:54 my inclination is it'll have to be inside the ironic pxe driver 19:41:04 I see, idk as ironic is going to build the tftp directory + create the configurations seems it's going to be ironic to inform neutron 19:41:21 particularly so that we can handle fail-over of the ironic-conductor nodes 19:42:30 lucasagomes: on the other hand -- https://github.com/openstack/nova/blob/master/nova/virt/baremetal/driver.py#L501 19:42:49 nova-baremetal is doing it, not the nova-baremetal-pxe sub driver 19:43:02 devananda, yea... but looking at lifeless patch here https://review.openstack.org/#/c/45589/1/nova/virt/baremetal/pxe.py 19:43:05 *is doing it today 19:43:17 seems it's being refactored 19:43:28 yep 19:43:36 but the API for that info is still going through nova/driver.py 19:43:48 ** nova/virt/driver.py 19:44:08 yea, there's a call self.driver.dhcp_options... 19:44:12 hmm 19:44:14 but I think we've wandered into the weeds now :) 19:45:35 hehe yea 19:46:16 it's cleanup 19:46:18 devananda, any luck finding that link about the discovery ramdisk? 19:46:21 the API is fine 19:46:27 lucasagomes: nope :( 19:46:39 :) np 19:47:38 lifeless: the question was wether we'll stick with dhcp boot information flowing (ironic->)nova->neutron or change to ironic->neutron 19:48:52 lifeless: and i suspect it'll need a longer discussion to tease out the implementation/complications of that change, at least for me 19:50:06 if no one has other topics, shall we wrap up a bit early? 19:50:19 +1 19:50:54 deploy ramdisk changes for Ironic? 19:52:00 yuriyz: that should end up being a fairly minor change, once all the API aspects around vendor_passthru are done 19:52:20 yuriyz, shoot :) 19:52:47 but if you have questions about it, dont hesitate to ask 19:55:28 well, let's wrap up. thanks everyone! 19:55:47 #endmeeting