19:00:06 #startmeeting Ironic 19:00:07 Meeting started Mon Oct 14 19:00:06 2013 UTC and is due to finish in 60 minutes. The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:08 #chair devananda 19:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:11 The meeting name has been set to 'ironic' 19:00:12 Current chairs: NobodyCam devananda 19:00:20 Welcome everyone to the Ironic meeting. The agenda can ofc be found at: 19:00:23 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 19:00:34 #toplic Greetings, roll-call and announcements 19:00:34 Who's here for the Ironic Meeting? 19:00:38 ping 19:00:46 \o 19:00:49 \o 19:00:52 here 19:01:06 Hi all 19:01:15 the only announcement I have is no new news on hoodies 19:01:17 hi 19:01:23 they are still in progress 19:01:44 NobodyCam: Is there still a change to get one for yuriyz? 19:02:08 yes we thing we are getting >= 20 19:02:17 cool 19:02:32 o/ 19:02:37 any other announcements 19:02:45 hey welcome GheRivero 19:02:51 (and lucasagomes0 19:03:05 and me 19:03:14 oh sorry linggao 19:03:22 (/me didnt see you) 19:03:24 no announcement from me 19:03:29 ok then 19:03:29 np, I was quiet. 19:03:31 #topic Hong Kong design summit paper talks 19:03:41 Ok I had a action item for a slot to discuss the summit papers so here it is :) 19:03:44 These are our current papers: (All great submissions) 19:03:46 #link http://summit.openstack.org/cfp/details/57 19:03:49 #link http://summit.openstack.org/cfp/details/97 19:03:51 #link http://summit.openstack.org/cfp/details/108 19:03:52 (sorry of the bulk paste) 19:03:55 #link http://summit.openstack.org/cfp/details/112 19:03:57 #link http://summit.openstack.org/cfp/details/139 19:04:00 #link http://summit.openstack.org/cfp/details/183 19:04:08 so 19:04:15 we have 5 slots 19:04:30 i've already moved the talk about exposign IPMI polling for Ceilometer to the Ceilometer track 19:05:10 and will be merging one or two of the above proposals 19:05:37 but all the ideas have been great, and there's still a few weeks if anyone has more 19:05:41 108 and 97 could go toghether 19:05:51 yep 19:06:25 and parts of 183 (scaling) could possibly be moved into 112 (HA) 19:06:34 to make the talks a little more focused 19:06:45 * NobodyCam likes ghe's 19:07:06 that's it from me -- any questions or feedback? 19:07:41 we can post coments on each paper 19:08:11 ok moving on then 19:08:14 #topic Outstanding, in-progress or Action Item updates 19:08:15 From the Agenda: 19:08:29 devananda to write framework for noav-ironic driver 19:08:29 lucasagomes to add CLI docs to ironic developer doc pages 19:08:29 romcheg to propose a non-gating job to -infra 19:08:29 romcheg to add python-ironicclient to devstack install scripts 19:08:29 devananda to think about a Transifex project for Ironic 19:08:32 romcheg looking at Ukrainian and Russian transifex translations 19:08:34 romcheg Check how i18n conplient we are 19:08:37 (again sorry) 19:09:04 yea will put on my todo list, I didn't do that yet 19:09:15 i've to make some changes on the CLI as well 19:09:16 devananda: I will bring up the nova review in client section 19:10:02 any updates on the Transifex stuff? 19:10:06 ah! yes 19:10:22 I think clarkb said it's all set up and ready for us to propose jobs 19:10:35 sweet :) 19:10:37 Are we at the stage where we can use ironic to deploy a baremetal node yet? If true, then we need to have a doc for how to do it. 19:10:38 w00t 19:10:45 I'm still trying to catch up with devstack and waiting until all blockers got merged to test tempest before submitting a job to infra 19:10:49 I was thinking about the translation I can translate it to brazilian portuguese as well 19:11:04 I am eager to see such a doc so that I can play it in my cluster. 19:11:20 linggao: not yet. it can turn power on/off to a node today. but deploy is untested, and doing it properly still requires the nova driver (not yet written) 19:11:37 also I maybe not the right topic but I hear nova client is gating in python3 on 19:11:43 by blockers I mean a fix with the policy and a problem with the time which is already merged 19:12:26 devananda, should we have a doc that we keep updating, that way the folks can play with the existing functions. 19:12:32 NobodyCam, afaik we were too, but we stopped cause of the dependency on the keystone client 19:12:42 ya 19:12:43 well it's there but it's non-voting in the moment 19:12:45 Now I can only play with the unit test cases 19:13:31 romcheg: i'll take a look at the policy changes you just psoted after the meeting 19:13:47 romcheg: assuming those are good and land today, anything else blockign the tempest patch (https://review.openstack.org/#/c/48109/) ? 19:13:47 we are doing much better on time then I had thought we would be 19:14:15 devananda: thanks. Yes, it looks like it's the only blocker now 19:14:26 :) 19:14:32 devananda, even how some of you setup your cluster for testing the APIs etc. 19:14:34 romcheg: great! I'll do that toady :) 19:14:39 Thanks 19:14:50 anything else on open / action items 19:14:57 regardign i18n compliance, do we have an open bug report? 19:15:12 that seems like something we could take off of romcheg's plate and let anyone else tackle in parallel 19:15:20 linggao: are you using devstack or dib for testing 19:15:46 splitting work is always good, I don't think we have a bug open 19:15:48 * lucasagomes checking 19:15:56 I though we had vage bug for it 19:16:07 lol 19:16:08 NobodyCam, I just use testr for now. But in the middle of setting up using devstack. 19:16:14 anyone_else will be happy to help 19:16:35 oh to good romcheg 19:16:51 lucasagomes: we have a few folks getting up to speed (linggao and rloo) and even splitting some of the API work out might be good for them 19:16:59 linggao: the walk thurs do work 19:17:19 linggao: https://wiki.openstack.org/wiki/Ironic 19:17:25 devananda, indeed, martyntaylor's also working on the api 19:17:45 I can def map somethings that needs to be done in the API 19:17:51 linggao: as far as my test env, i have a seed VM and an ironic VM which is running all the services in it. 19:17:52 NobodyCam, thanks. I'll follow that doc. 19:18:03 lucasagomes: # action??? 19:18:10 NobodyCam, could be :) 19:18:21 linggao: so i am testing in that "ironic vm" when i need to run things outside of venv 19:18:24 devananda, lucusagomes, yes. I am willing to take more works. 19:18:32 Please assign me something. 19:18:40 linggao: thanks! 19:18:42 np 19:19:03 #action map somethings that needs to be done in the API 19:19:07 gah 19:19:17 #action lucasagomes map somethings that needs to be done in the API 19:19:22 lucasagomes: what about bookmark links? 19:19:32 that's one :) 19:19:32 #action devananda to update ironic wiki tripleo walkthrough to include "how to update code in the undercloud" 19:19:47 bookmark links currently are retuning 404 19:19:55 if u wanna take a look at it linggao 19:20:04 devananda: ^^^ with rebuilding 19:20:14 NobodyCam: withOUT rebuilding the undercloud 19:20:37 sounds like a adhoc script that would be cool 19:20:48 NobodyCam: i've got it so that I ssh into undercloud, sudo su -, cd $somepath, git review -d ###, service ironic-conductor restart 19:20:49 updateironic.sh 19:20:52 something like that 19:20:55 lucasagomes, what do you want me to take a look? 19:21:01 nice 19:21:03 :) 19:21:22 #topic Integration and testing 19:21:32 lucasagomes, linggao: should bokmark links return redirects to the latest version of the API or just resources? 19:21:37 should catch up the topic 19:21:38 linggao, the API generates some bookmarks links, currently they are not working 19:21:51 we talk in the API topic about it 19:21:55 sorry NobodyCam 19:21:58 lucasagomes, sure. I'll take a look. 19:21:59 lol 19:22:28 I think we covered the devstack issue so moving on thru 19:22:51 #topic Python-IronicClient 19:23:04 I'm finishing up removing of the mox from the unit testcases with rloo. 19:23:16 WOW this is suck a awesome review to see :) 19:23:18 #link https://review.openstack.org/#/c/51328/ 19:23:24 we'll free of mox very soon. 19:23:29 ironic client... there's one thing needed which is blocking the ironic driver on nova 19:23:32 linggao: oops 19:23:36 which is access nodes->ports 19:23:45 like GET /nodes//ports 19:24:03 NobodyCam, np. I am slow at typing. 19:24:08 another neat feature that needs to be added is multi operations when creating a patch to a resource 19:24:08 :) 19:24:18 (so is /me) 19:24:20 like add,remove,replace in the same CLI cmd 19:24:40 and documentation 19:24:40 lucasagomes: client needs driver-list too 19:24:50 NobodyCam, yea but that's needed in Ironic first 19:24:55 :) 19:25:08 lucasagomes: i would put multi-operation-in-cli pretty low on the priority list, fwiw 19:25:28 lucasagomes: validate-on-create would basically solve the current need for that 19:25:44 devananda, indeed, and we need to talk about it on the API topic 19:26:09 lucasagomes: and if, at some point, we have a driver update that makes it require different fields, we'd need to tag a db migration in the same patch 19:26:17 i haven't mentioned that before :) 19:26:38 :-p 19:26:46 but basically, we should try not to break nodes that might currently be working when we change a driver's required fields 19:27:15 do we have anything on how to do a db change? 19:27:25 yea, well I was thinking about the required fields, actually I've a patch in gerrit that makes driver/driver_info required at node creation 19:27:30 its WIP 19:27:31 NobodyCam: there are db migrations already in the tree. just follow the patterns 19:27:37 :) 19:27:41 it works but it's kinda hacky 19:28:01 cause the way that TaskManager works, we need to create the node before and then validate it 19:28:08 yea 19:28:10 if validation fails we delete that node 19:28:18 anything else on the cli 19:28:32 lucasagomes: ieek 19:28:38 NobodyCam, not really, we are already talking about the API hehe 19:28:46 #topic API discussion 19:28:51 :-p 19:29:03 devananda, also, should properties be required? 19:29:04 ieek was for the delete comment 19:29:18 NobodyCam, yea :( I know 19:29:29 that's why I got me thinking about the validation at creation time 19:29:51 lucasagomes: rather than API:create, RPC:validate, if fails: API:delete 19:30:11 lucasagomes: what about moving all the create logic into the conductor? 19:30:29 lucasagomes: and passign the dict over RPC. the return over RPC would either be a node obj or an exception 19:30:42 devananda, will look a bit better, but we still need to create the node in the db first 19:31:04 cause of the taskmanager rigth? it puts some flags on the db 19:31:08 yep 19:31:18 also we talked about restarting. what would happen if someone created a node then removed the driver and restarted 19:31:51 lucasagomes: could also create an empty node in the db, then validate the whole dataset 19:32:18 lucasagomes: rather than risk that a node with data in the db could linger ,if the api crashed during validation 19:32:25 devananda, yea... but another thing about having it as required is the size of the CLI to create a node 19:32:28 (not great either way -- an empty node is bad, too) 19:32:35 lucasagomes: true 19:32:44 NobodyCam, hmmmmmmmmmmm it will fail when he tries to deploy/powerupa node 19:32:53 NobodyCam, cause there's validations at the start of each of those actions 19:32:58 lucasagomes: then we don't require nodes to have valid data for update. 19:33:06 NobodyCam, and if the driver is not there it's going to fail anyway :D 19:33:18 devananda, that's what I was thinking about 19:33:30 after starting coding, I thought that it would be a pain to people to create a node 19:33:42 if all those fields are required 19:34:07 devananda, you know what would be good, if we have someway to trigger the validation 19:34:21 like after u input all the data but before deploying/powering up 19:34:28 * devananda face-palms 19:34:36 node.validate() 19:34:43 from the api 19:34:43 it's actually going to be impossible to validate driver.deploy at node creation time 19:35:07 since nova won't populate the details for a deploy until someone actually creates a nova instance and spawn()s it 19:35:10 so 19:35:12 yes 19:35:17 we have to allow update on invalid data sets 19:35:20 devananda, a-ha! 19:35:31 right 19:35:36 I will remove the validations from update 19:35:43 #action :) 19:35:51 devananda, also, chassis_id, required or not? 19:35:59 #action lucasagomes to remove validation from API update method 19:36:05 it's required for ports so I think it makes sense to be on nodes as well 19:36:35 lucasagomes: yea. even if in a small deploy, someone just creates one dummy chassis to hold all their nodes 19:36:44 i think it's fair that we say node.chassis_id NOT NULL 19:36:46 so we have a consistent workflow to create the resources 1. create chassis 2. create the node for the chassis 3. create the ports for the nodes 19:36:56 devananda, +1 19:37:09 yea +1 19:37:18 4. populate node's driver info (for the power driver) 19:37:22 +1 19:37:39 :) yea 19:37:41 so in terms of manually triggering a driver.interface.validate() 19:37:50 we may want to expose which interfaces pass/fail 19:38:22 devananda, yea, i gotta think how we are exposing that tho 19:38:31 eg, GET /nodes/xxx/validate might return {'power': True, 'deploy': False, 'console': NotSupported} 19:38:34 or something 19:38:50 sounds reasonable for me 19:39:07 at least the user are more secure to press the "deploy button" 19:39:11 if he does validate it first 19:39:25 yea 19:39:56 is that all for api? 19:40:08 as far as prioritization, i dont think we need that for the nova driver 19:40:35 and users shouldn't be starting a deploy from the CLI :) 19:40:49 :) 19:40:51 but it will probably be useful in troubleshooting, etc, at some point 19:40:57 so #lowpriority, IMO 19:41:01 shouldn't or can not 19:41:25 oh yea... and won't take much time to implement as well... anyhoo 19:41:43 off the top of my head we don't have anything else for the API (unless we want to talk about vendor_passthru) 19:41:53 NobodyCam: well. users will be able to do anything the API service exposes if they write their own clients (which they eventually will) 19:42:35 devananda: ahh but not thru the ironic-cli 19:42:41 so I say "shouldn't" :) 19:42:46 thru the api 19:43:06 hehheh 19:43:13 the CLI is just what we choose to give as a reference to users, to enable adoption and usage of the API. 19:43:21 it's not going to be the only client 19:43:24 vp or move on 18 minutes 19:43:37 nothing on vp from me 19:43:49 vp?! 19:43:59 vender-passthru 19:44:02 ahh 19:44:03 lol 19:44:08 #topic Java Driver 19:44:08 so not sure anyone saw my post over theweekend.. comes down to x10 is out InSte0n 19:44:11 is what is out now. I see how to get insteon working in linux. 19:44:16 yea I'm waiting for HK to talk more about vp 19:44:36 any q/c on coffee driver? 19:45:02 does it make cappuccino?? 19:45:11 :-D 19:45:20 it could if you had a cappuccino maker 19:45:26 sweet 19:45:43 ok then 19:45:45 #topic Food for Thought / Open Discussion 19:46:00 open floor 19:46:05 devananda, how are we exposing nodes//ports on the CLI? 19:46:07 all question welcome 19:46:15 node-port-list ? 19:46:32 hrm.... nova boot image=cappuchino flavor=twelve_ounce 19:46:35 sorry, distracted by coffee :) 19:46:41 lol 19:46:42 lol 19:46:43 it's cool 19:46:52 How inform deploy ramdisk of ironic's api url? 19:47:03 kernel param? 19:47:18 yuriyz: thats what we do now 19:47:40 humm /me checking 19:47:40 A simple question on the CLI, will the ironic CLI be exposed through nova? 19:48:00 You may have disscussed this before. 19:48:09 lucasagomes: that works. or what about: ironic list-ports [] 19:48:24 linggao, nova will have a driver that will be written using the ironic cli libs (which the cli uses as well) 19:48:34 linggao: ironic has its own API endpoint 19:48:55 linggao, https://review.openstack.org/#/c/51328/ 19:49:02 linggao: i am writing a noav driver that will use python-ironicclient library and talk to ironic API enpoint 19:49:19 devananda, lucuasagomes, I see. thanks 19:49:20 linggao: and the cloud admin can also use ironic CLI to talk to the ironic API endpoint, eg. to enroll nodes, check status of things, etc 19:49:34 devananda, list-ports [] sounds good 19:49:37 reusing the command 19:49:40 I see. 19:49:46 linggao: but to manage a deploy, user will still call nova 19:50:06 linggao: eg, nova boot --flavor ironic.large --image ubuntu13.04 ... 19:50:31 linggao: and nova scheduler will know that ironic.large flavor type should be routed to a nova-compute node that is configured with the 'ironic' driver 19:50:40 devananda, but hmmmm it's not very explicit, I mean node-port-list at least says ur listing the ports on that node 19:50:43 then nova-compute's ironic driver will do the work of deploy, power, etc 19:50:52 davananda, I see. but can they also boot up a node using ironic CLI directly? 19:50:53 devananda, I would stick to node-port-list sounds more comprehensible 19:50:57 looks* 19:51:13 lucasagomes: node-ports-list is certainly clearer, yes 19:51:22 cool 19:51:35 linggao: well. no. 19:51:42 ok 19:51:52 linggao: technically, anything that nova will do to ironic, a user could also do manually 19:52:04 linggao: but it would be difficult and is certainly not the "right" thing to do 19:52:18 linggao: when deploying openstack with ironic, Nova should manage the deployment process. 19:52:31 davananda, thanks 19:52:41 anothe question 19:52:45 console 19:53:17 Should we feedback the console from ipmi to nova? 19:53:21 linggao: yes 19:53:45 linggao: nova alraedy has an API for exposign console. we should interoperate with that as much as possible 19:54:13 yuriyz: https://github.com/openstack/diskimage-builder/blob/master/elements/ramdisk/extra-data.d/scripts/init#L41 19:54:14 linggao: general rule -- don't reinvent the wheel. so if another service in openstack already does it, we should just use that 19:54:30 lol moved sense I last looked 19:55:01 5 minute bell 19:55:02 davananda, like we talked on the ironic channel, I can look into it. I think currently nova gets the console from the vn hypervisors 19:55:37 davananda, vn/vm 19:56:08 davananda, not sue it can get console for baremetal yet. 19:56:29 linggao: yes. one difference -- nova-compute is running on same host with vm hypervisor. bare metal console is on a network (eg, serial port or SOL interface) 19:56:45 linggao: so we may need to d osomething like run a SOL proxy on the ironic-conductor or nova-compute host 19:57:22 and teach nova to return that 19:57:32 devananda, yes, we need have that path set up. 19:57:33 should I ask about the xcat way of doing it 19:57:40 sol that is 19:58:00 linggao: you may also want to see how this was done for the initial nova-baremetal driver. 19:58:18 they had some support for SOL, but I did not get it to work 19:58:28 no I 19:58:32 xCAT has a command called rcons, it gets the console through ipmitool 19:58:56 two minuts 19:59:17 but jbhonso is writing code to get it from native IPMI. 19:59:27 let move anything open back to our home channel 19:59:37 Great meeting guys 19:59:45 yea, time's up! thanks everyone -- let's continue in #ironic 19:59:50 last word: 19:59:51 :) thank you all 19:59:56 #endmeeting