19:00:49 <NobodyCam> #startmeeting Ironic
19:00:50 <openstack> Meeting started Mon Sep  9 19:00:49 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:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:54 <openstack> The meeting name has been set to 'ironic'
19:00:58 <NobodyCam> agenda for the meeting is found @:
19:00:59 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:01:04 * devananda waves
19:01:10 <NobodyCam> Looks like we have a full agenda today, so lets jump on in
19:01:10 <NobodyCam> #topic Greeting and roll-call and announcements.
19:01:11 <NobodyCam> who's here for the ironic meeting? And May I be the first to welcome Devananda back from the land of brunning things :)
19:01:20 <lucasagomes> o/
19:01:22 <dkehn> lurking
19:01:27 <romcheg> o/
19:01:33 <NobodyCam> dkehn: you are on our agenda :-p
19:01:38 <yuriyz> here
19:01:45 <dkehn> dkehn, non-lurking
19:01:54 <NobodyCam> welcome every  one
19:02:09 <NobodyCam> fist up
19:02:10 <NobodyCam> Rummor mill: There may be Ironic hoodies for Hong Kong. (This is a unconfirmed rummor at this point)
19:02:31 <NobodyCam> will need sized for every one
19:02:39 <NobodyCam> *sizes
19:02:41 <dkehn> dkehn, large
19:02:50 <lucasagomes> small for me
19:02:57 <devananda> may i suggest an etherpad or gdoc spreadsheet to collect that info?
19:03:04 <NobodyCam> ++
19:03:04 <lucasagomes> devananda, +1
19:03:06 <romcheg> =1
19:03:07 <NobodyCam> not here
19:03:08 <romcheg> +1
19:03:12 <NobodyCam> :)
19:03:16 <NobodyCam> will get that later
19:03:30 <NobodyCam> just fyi :)
19:03:32 <NobodyCam> Announcements:
19:03:32 <NobodyCam> Hong Kong design summit: call for Ironic papers!
19:03:32 <NobodyCam> Submit pepers here:
19:03:33 <NobodyCam> #link http://summit.openstack.org/
19:03:49 <NobodyCam> #chair devananda
19:03:50 <openstack> Current chairs: NobodyCam devananda
19:04:29 <NobodyCam> any one have any thinghts for design papers
19:04:40 <NobodyCam> *thoughts
19:04:42 <dkehn> cue crickets
19:04:43 <devananda> on the summit design session proposals, please be sure to select either Ironic or TripleO, depending on which one you're going to talk about. poke me or lifeless if you're unsure which one your topic fits best in
19:05:12 <NobodyCam> :)
19:05:16 <romcheg> For Ironic we can think about RBAC
19:05:34 <lifeless> or poke both :)
19:05:39 <NobodyCam> :)
19:05:41 <romcheg> That will make Ironic more standalone service
19:05:53 <lifeless> romcheg: is there a reason to have Ironic be standalone?
19:06:05 <devananda> let's not talk about specific ideas in the meeting right now
19:06:13 <NobodyCam> +1
19:06:18 <lifeless> oops, didn't note the channel. Very sorry!
19:06:19 <devananda> just submit them and we'll discuss on the ML / on IRC if need be
19:06:21 <devananda> :)
19:06:32 <romcheg> Will do that
19:06:37 <devananda> romcheg: ty
19:06:47 <NobodyCam> ok moving on
19:06:53 <NobodyCam> #topic Testing
19:06:54 <NobodyCam> The devStack patch has landed! Way to go Roman!
19:07:18 <romcheg> I think I can start working on tempest now
19:07:36 <NobodyCam> :)
19:07:50 <NobodyCam> any comments / questions?
19:08:09 <romcheg> yes
19:08:23 <NobodyCam> shot
19:08:43 <romcheg> Currently devstack creates a single config for both api and conductor.
19:08:51 <romcheg> Should we separate them?
19:09:17 <NobodyCam> romcheg: I don;;t think there is big needfor that
19:09:21 <devananda> for single-node testing with devstack,, i think single config is probably ok
19:09:34 <devananda> unless there is a concrete reason to split them, i would avoid premature optimization
19:09:36 <NobodyCam> in dib element I split logging conf
19:09:47 <NobodyCam> but main config is singular
19:10:00 <lucasagomes> yea it's easier to have one config for testing
19:10:15 <romcheg> ok, no questions on that :)
19:10:30 <NobodyCam> another q? romcheg is this upto date?
19:10:35 <NobodyCam> #link https://wiki.openstack.org/wiki/Ironic#Try_it_on_Devstack
19:11:09 <romcheg> NobodyCam: yes, it is. I updated it imediately after the patch landed to devstack
19:11:13 <NobodyCam> :)
19:11:16 <NobodyCam> w00t
19:11:19 <jdob> yay for devstack support
19:11:21 <devananda> nice!
19:11:38 <NobodyCam> rtmo?
19:12:05 <NobodyCam> moving on
19:12:11 <NobodyCam> and of course the DIB element(oh thats /me):
19:12:11 <NobodyCam> 2 of 4 landed :) Remaining is:
19:12:12 <NobodyCam> #link https://review.openstack.org/44500 (element itself)
19:12:12 <NobodyCam> and
19:12:12 <NobodyCam> #link https://review.openstack.org/44516 (yaml heat template)
19:12:14 <NobodyCam> I'll work the last ones through this week!
19:12:49 <NobodyCam> any q/ c?
19:13:38 <NobodyCam> ok movnin along
19:13:40 <NobodyCam> #topic in-progress tasks
19:13:40 <NobodyCam> Gongrats to Ghe PXE has LANDED!
19:13:46 <NobodyCam> :)!!!!!
19:14:27 <lucasagomes> oh yea!! a huge step forward on making ironic usable :)
19:14:35 <NobodyCam> oh ya
19:14:39 <NobodyCam> :)
19:14:43 <lucasagomes> I think I asked in the review, but someone knows how he actually tested that?
19:15:35 <NobodyCam> I did speak with him about that ... but cannt recall just now what his answer was
19:15:46 <devananda> GheRivero: around?
19:15:56 <lucasagomes> ok, yea I looked in the review but I got no answer there
19:16:04 <lucasagomes> it's cool I can talk to him when he's online
19:16:10 <romcheg> Regarding the the authentication: AFAIR I reported last time that the current implementation of Ironic authentication allows domain admins to use the API
19:16:10 <NobodyCam> :)
19:17:20 <NobodyCam> any more q/c on PXE
19:17:48 <NobodyCam> moving on
19:17:51 <NobodyCam> And Now for something completely different:
19:18:03 <NobodyCam> the Ironic Client Libary
19:18:04 <NobodyCam> #link https://github.com/openstack/python-ironicclient (Repo)
19:18:04 <NobodyCam> Patch to add the initial files:
19:18:04 <NobodyCam> #link https://review.openstack.org/#/c/45144
19:18:28 <NobodyCam> :)
19:18:46 <yuriyz> good start!
19:19:04 <NobodyCam> will need to do some design on how and what it needs to do
19:19:32 <NobodyCam> example how will me handle nova baremetel-node-list
19:19:47 <NobodyCam> functionality
19:20:13 <romcheg> I think we need an etherpad doc for that
19:20:18 <NobodyCam> the above revire is just the basic framwork
19:20:21 <lucasagomes> maybe we should open an etherpad for that and starting throwing the ideas there
19:20:27 <NobodyCam> ++
19:20:28 <lucasagomes> romcheg, +1
19:20:49 <NobodyCam> we have
19:20:54 <NobodyCam> #link https://etherpad.openstack.org/IronicWhiteBoard
19:21:08 <NobodyCam> welcome back linggao
19:21:23 <linggao> Hey NobodyCam.
19:21:23 <NobodyCam> can we ajust use that one?
19:21:42 <lucasagomes> I'm fine with that one
19:21:46 <NobodyCam> :)
19:21:48 <lucasagomes> there's a section for it there already
19:21:57 <lucasagomes> == Python client library ==
19:22:10 <NobodyCam> :)
19:22:13 <romcheg> +1 to the same document.
19:22:17 <NobodyCam> we'll start using it
19:22:29 <devananda> sounds good :)
19:22:52 <NobodyCam> any other q/c ok to move on?
19:23:16 <NobodyCam> moving on
19:23:17 <NobodyCam> #topic API discussion
19:23:18 <NobodyCam> Our Epic "Patch" has landed : congrats Lucas
19:23:25 <lucasagomes> :)
19:23:48 <lucasagomes> as romcheg rightly pointed out... we might need to improve the validation method later
19:23:55 <NobodyCam> yes!!!!
19:24:17 <NobodyCam> romcheg: you want to file a bug to track that?
19:24:33 <romcheg> I think that looks more like a BP
19:24:38 <NobodyCam> :)
19:25:10 <romcheg> So if you don't mind I can file a BP :)
19:25:20 <lucasagomes> romcheg, +1 :)
19:25:29 <NobodyCam> as they say: Just Doit
19:26:01 <NobodyCam> with that our new big epic
19:26:02 <NobodyCam> Next up is vendor_passthru
19:26:02 <NobodyCam> Many comments can be found at:
19:26:03 <NobodyCam> #link https://review.openstack.org/#/c/41976
19:26:09 <devananda> as an aside, I'd suggest small things -> bug. big work that we may want to discuss at the summit -> BP.
19:26:39 <NobodyCam> :) kninda what DS's are for huh
19:26:42 <NobodyCam> :-p
19:27:04 <romcheg> devananda: I'll do as you wish :-P
19:27:06 <devananda> right. what i mean, there's explicitly a way to link design sessions to BPs (but not to bugs)
19:27:42 <NobodyCam> :)
19:28:07 <devananda> we need some degree of vendor_passthru for the PXE driver
19:28:29 <NobodyCam> yuriyz: did I see you?
19:28:35 <lucasagomes> so, vendor_passthru... there's two patches in the review system right now, one for the API and one implementing the server side
19:28:38 <devananda> but to what degree we need to return a tracking token and allow users to poll status on that token is, at the moment, not clear to me
19:28:43 <yuriyz> yes
19:28:51 <lucasagomes> but there's one thing missing, we need to improve the client's feedback
19:29:04 <yuriyz> Any idea about deploy monitoring?
19:29:17 <devananda> IMHO, adding tracking token right now is premature
19:29:25 <lucasagomes> our currently implementation (in the review) doesn't allows clients to monitor their requests, not even knowing if the validation of the data passed or not
19:29:32 <devananda> because we already have a unique ID (the node UUID) which can be polled for updates
19:30:31 <devananda> lucasagomes: changing pass_vendor_info self.cast to self.call would allow such feedback
19:30:46 <lucasagomes> devananda, yes! but won't be async then
19:30:47 <devananda> lucasagomes: at the cost of stalling hte API request if that call is going to take a while, which is bad
19:30:50 <devananda> right
19:30:54 <yuriyz> But deploy is long process
19:31:06 <devananda> we could make the async operation happen within the manager
19:31:20 <devananda> pass info as a cast, then let periodic_task handle the work. not saying I like that solution ....
19:31:29 <lucasagomes> what if the we make the validation sync, and then we call cast to the driver do the actual work?
19:31:33 <devananda> **pass info as a call**, i mean
19:31:52 <devananda> hm
19:32:01 <lucasagomes> so it would look like... validation passed, request was accepted
19:32:22 <NobodyCam> i feel we need at least that level
19:32:23 <lucasagomes> return 202, with no body message
19:32:29 <devananda> so have the rpcapi.pass_vendor_info invoke two RPC operations -- first, call('send the info'), then second, cast('now do the work')
19:32:32 <devananda> ?
19:32:51 <lucasagomes> devananda, that's how I see it :/
19:32:53 <lucasagomes> 1 call and 1 cast
19:32:55 <yuriyz> lucas, +1
19:33:14 <devananda> i think that would work
19:33:19 <yuriyz> two methods?
19:33:23 <devananda> no, one method
19:33:29 <NobodyCam> the client could then wrap the two calls?
19:34:13 <devananda> ironic/conductor/rpcapi.py:ConductorApi.pass_vendor_info() would have two function calls inside it
19:34:27 <devananda> self.call(context, self.make_msg('validate_vendor_info', ...)
19:34:27 <lucasagomes> NobodyCam, it's one call
19:34:37 <devananda> self.cast(context, selfmake_msg('do_vendor_work', ...)
19:34:49 <devananda> er... no. nvm, that doesn't work either
19:34:57 <lucasagomes> validate -> get return, if positive cast, and then return the info about the validation
19:35:05 <lucasagomes> if negative just return the info w/o calling cast
19:36:21 <NobodyCam> as;ldkj
19:36:27 <NobodyCam> gah puppy sorry
19:36:59 <devananda> actually, ignore my "nvm" -- it does work. 1 call. if succeed, then cast & return.
19:37:31 <lucasagomes> I say because, idk if it makes much sense about returning a request accepted return code, without validating the data before
19:37:33 <NobodyCam> if fail return fail msg to user?
19:37:41 <devananda> if the call to validate the vendor info failed, an exception should have been raised on the remote end, which would bubble up here (and that's fine, i think)
19:38:52 <NobodyCam> :) any thing else on vp thru
19:39:08 <NobodyCam> we can chat more in channek
19:39:11 <devananda> nothing else fro mme - I'll add comments to the review.
19:39:13 <NobodyCam> *chennel
19:39:19 <NobodyCam> :)
19:39:40 <lucasagomes> I'm good also
19:39:45 <NobodyCam> #topic Food For Thought / open discussion
19:39:47 <romcheg> No questions
19:39:50 <yuriyz> devananda: ok
19:40:04 <NobodyCam> Don's ( dkehn ) Neutron patches have Landed! How will this impact Ironic?
19:40:22 <NobodyCam> see dkehn I said you on our agenda
19:40:24 <NobodyCam> :-p
19:40:41 <dkehn> yeah, but nothing to say on that one
19:40:58 <NobodyCam> congrats man!!!
19:41:02 <dkehn> the patch provide s for setting up the PXE boot params
19:41:03 <NobodyCam> that was hard work
19:41:18 <lucasagomes> well it def helps us in our merge of the nova bm deploy helper in the ironic code database
19:41:30 <dkehn> not really , but did require and incredible amount of patences
19:42:03 <dkehn> lifeless, also has changes for the patch once we move on https://review.openstack.org/#/c/45589/
19:42:20 <lucasagomes> #link https://review.openstack.org/#/c/45589/
19:42:22 <NobodyCam> :)
19:42:25 <NobodyCam> ty lucasagomes
19:43:05 <devananda> dkehn: have the changes for nova baremetal driver (so that it can use neutron's pxe ports) landed?
19:43:26 <dkehn> the initial yes
19:43:37 <devananda> dkehn: if so,we could probably adapt that nova-baremetal patch to the ironic-pxe driver code
19:43:42 <lifeless> devananda: https://review.openstack.org/#/c/45126/4 is a fixup needed.
19:43:44 <devananda> rather than rewrite it
19:43:49 <dkehn> https://review.openstack.org/#/c/31061/
19:43:58 <dkehn> https://review.openstack.org/#/c/45126/
19:44:08 <devananda> thanks. looking
19:44:13 <lifeless> devananda: I've asked for and gotten an FFE for it; it just needs two x +2.
19:44:16 <dkehn> there was a bug in the initial release
19:44:23 <NobodyCam> #link https://review.openstack.org/#/c/31061/
19:44:31 <NobodyCam> #link https://review.openstack.org/#/c/45126/
19:44:40 <dkehn> NobodyCam, sorry
19:44:56 <NobodyCam> not at all
19:45:01 <NobodyCam> :-p
19:45:13 <NobodyCam> just makes them easier to find later
19:45:53 <NobodyCam> open floor
19:46:01 <NobodyCam> any comments question at all
19:46:40 <NobodyCam> linggao: are you getting back in to the swing of things are you going to revive your power patch?
19:47:32 <linggao> NobodyCam, yes. I'd like to get in 3 pathces
19:47:42 <linggao> 1. renamting ipmi.py to ipmitool
19:47:50 <linggao> 2. native ipmi driver.
19:48:28 <NobodyCam> :)
19:48:41 <linggao> 3. set_node_state_change (something like that)
19:48:52 <linggao> hope they will go through this week.
19:49:04 <NobodyCam> :) looking forward to seeing them :)
19:49:15 <linggao> great! thanks
19:49:40 <lucasagomes> :)
19:49:49 <NobodyCam> anyone thing else? we going to get out of here earily today
19:50:30 <NobodyCam> last words: design summit papers!!! please submit any ideas
19:50:47 <lucasagomes> maybe use the last 10 minutes to talk about the interface with nova
19:50:59 <NobodyCam> ++
19:51:02 <lucasagomes> devananda, you have any thoughts here? will ironic be a driver for nova?
19:51:24 <NobodyCam> lucasagomes: th client lib
19:51:26 <romcheg> Shouldn't that be just another driver?
19:51:35 <NobodyCam> import python-ironicclient
19:52:17 <devananda> so
19:52:30 <devananda> we'll need to create an ironic driver for nova, yes
19:52:50 <devananda> it will implement nova's internal driver api, and it will wrap python-ironicclient
19:53:09 <devananda> so, eg, a call to "nova boot" will get routed roughly like this
19:53:38 <devananda> nova-api -> nova-scheduler -> nova-conductor [ -> nova-compute ?? ] -> nova/virt/ironic/driver.py
19:54:09 <devananda> class IronicDriver
19:54:22 <devananda> IronicDriver.spawn(...)
19:54:33 <devananda> that will issue API calls to ironic-api
19:54:34 <devananda> and so on
19:54:48 <lucasagomes> gotcha
19:54:52 <NobodyCam> :)
19:54:55 <devananda> look at nova/virt/baremetal/driver.py:BaremetalDriver for an example of the minimal set of methods we'll need to implement
19:55:09 <devananda> as an interface between nova's Driver API and the Ironic service
19:55:22 <yuriyz> I thhink
19:55:33 <yuriyz> think we need a BP
19:55:35 <romcheg> I have the dumbest question here: why do we need nova if it works like a proxy for Ironic when booting a BM node?
19:56:16 <devananda> eg, spawn(), reboot(), destroy(), get_info(), list_instances(), get_hypervisor_type(), ....
19:56:29 <lucasagomes> right, and some future features that we are going to expose in the ironic api, will also be exposed in the driver? For e.g the hardware recovery, or even the vendor passrhru?
19:56:34 <devananda> romcheg: there are many, many things which nova interacts with during provisioning of a VM
19:56:43 <NobodyCam> romcheg: we are building the replacment for nova baremetal wihich will get pulled out
19:57:06 <devananda> romcheg: ironic is a service which deploys an image on to a machine. it's acting rather like libvirt in that sense
19:57:23 <devananda> romcheg: ironic is not replacing nova :)
19:57:33 <romcheg> makes sense :)
19:57:37 <NobodyCam> -p
19:57:48 <NobodyCam> i should have made that more clear
19:57:57 <NobodyCam> 3 minute bell
19:58:02 <lucasagomes> :) that's a straight forward answer
19:58:03 <devananda> lucasagomes: yes, once we have feature parity with the current baremetal driver, we'll start looking at the new features
19:58:26 <devananda> lucasagomes: and performance optimizations, HA, etc
19:58:53 <lucasagomes> devananda, oh yea... we have to improve the deploy process performance
19:59:07 <linggao> There will be a new peoject called Tuskar, what is the relationship between it and ironic?
19:59:08 <lucasagomes> but we have no time to talk about it now cause there's only 1 minute left
19:59:10 <devananda> lucasagomes: vendor_passthru may never be exposed via Nova's API. also things like firmware mgmt, probably not going to go through Nova (though there are disucssions about that...)
19:59:22 <devananda> right! time's up :)
19:59:35 <lucasagomes> :)
19:59:36 <NobodyCam> we can move back to our channel
19:59:39 <lifeless> T=-1 :)
19:59:42 <linggao> ok
19:59:44 <devananda> so, please submit design ideas! :)
20:00:00 <lifeless> linggao: tuskar layers on tripleo layers on ironic
20:00:03 <NobodyCam> ok good meeting everyone
20:00:10 <NobodyCam> #endmeeting