19:01:32 <devananda> #startmeeting ironic
19:01:33 <openstack> Meeting started Mon Jun 10 19:01:32 2013 UTC.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:36 <openstack> The meeting name has been set to 'ironic'
19:01:58 <devananda> I see have the same agenda as last week
19:02:01 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:02:02 <anteaya> linggao: http://eavesdrop.openstack.org/meetings/ironic/
19:02:15 <devananda> as a reminder, anyone's welcome to edit that wiki page and add items to the agenda before a meeting
19:02:42 <devananda> we've got several things in progress, hopefully those folks are around to report?
19:03:04 <devananda> db object model made some good progress. romcheg got the essential parts ported from Nova last week
19:03:22 <devananda> and we're working on the chassis/node/port object models now
19:03:23 * anteaya applauds romcheg
19:03:28 <devananda> #link https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/ironic-object-model,n,z
19:03:50 <devananda> i think node is done -- could use some reviews ;)
19:04:06 <anteaya> great
19:04:11 <devananda> the API/RPC layer is stalled on the object models
19:04:38 <devananda> martyntaylor, if you're around, want to add anything about the API?
19:05:28 <devananda> k, feel free to jump in later if you are
19:05:45 <devananda> after last meeting's lengthy chat about the internal driver api
19:05:56 <devananda> i rewrote it ... https://review.openstack.org/#/c/31692/
19:06:38 <devananda> pending further reviews still, but i'm pretty happy with it
19:06:42 <martyntaylor> devananda: I shall read that
19:06:45 <anteaya> nice work
19:07:02 <devananda> it's unfortunately a massive and sprawling patch
19:07:19 <NobodyCam> kinda needs to be
19:07:56 <devananda> we can come back to that if folks want to talk about it in the meeting
19:08:04 <devananda> or just add comments on gerrit :)
19:08:13 <linggao> Is there a way for us to pull out the your latest code that's pending for review?
19:08:25 <devananda> linggao: that's what gerrit is there for
19:08:42 <martyntaylor> so wrt API we still had a few things that I don't think we fully agreed on.  i.e. how to handle vendor actions on driver
19:08:47 <devananda> linggao: you can git pull directly from gerrit to get the single patch, or the series of dependent patches
19:08:59 <martyntaylor> devananda: do you want to bring that up in here?  Or shall we tackle that post v1
19:09:12 <devananda> martyntaylor: ah, that's right.
19:09:32 <devananda> martyntaylor: i think we can bring that up here in a few minutes.
19:09:38 * NobodyCam notes the v6 ip :)
19:09:56 <devananda> real quick update on the image utils - some of it landed in olso, but the main work in glanceclient is blocked currently
19:10:04 <devananda> pending some additional refactoring by Ghe
19:10:13 <devananda> so the PXE driver is subsequently blocked on that
19:10:31 <devananda> that's all for my in-progress updates
19:10:32 <devananda> #topic API vendor passthru
19:10:55 <devananda> martyntaylor: one of my concerns with how we implement the vendor extensions is
19:11:11 <devananda> martyntaylor: that I think drivers should be able to exist out-of-tree
19:11:22 <devananda> iow, be installable as a separate package, loaded via entrypoints
19:11:59 <martyntaylor> right
19:12:27 <martyntaylor> so are you thinking registration i.e. POST via the API, depending on permissions with inclusion of a binary
19:12:32 <martyntaylor> something along those lines?
19:12:39 <martyntaylor> or something independent of the API
19:13:07 <devananda> i'm thinking there are two potential avenues, i'm not sure which is better yet
19:13:40 <devananda> 1) vendor area of the API doesn't do anything besides bundle up the request (URI and data) and pass it, over RPC, to the manager
19:13:43 <devananda> or
19:13:53 <devananda> 2) load extensions into the API
19:14:07 <martyntaylor> sure
19:14:58 <devananda> that'll allow the vendor to define their own API (for the things Ironic cant do) and the deployer can install the extension(s) and configure Ironic to use it/them
19:15:34 <devananda> and vendors can maintain out-of-tree drivers, at their expense (not burdening Ironic with the code maintenance)
19:15:34 <martyntaylor> right
19:15:37 <devananda> thoughts?
19:15:48 <martyntaylor> that sounds like a reasonable approach
19:16:06 <devananda> lifeless: want to chime in before we go further?
19:16:08 <JimJiang> agree
19:16:14 <NobodyCam> where would security be enfourced
19:16:14 <lifeless> hi, sec to get context
19:16:40 <martyntaylor> devananda: If at all possible, (and I don't understand the problem enough i think to make a decision) but it would be good if we can some how represent this stuff in a standard way across the API
19:16:42 <devananda> martyntaylor, JimJiang - as I tossed out two ideas, which are you referring to as reasonable :)
19:16:54 <NobodyCam> enforced
19:17:02 <martyntaylor> devananda: the latter
19:17:11 <devananda> k
19:17:22 <martyntaylor> devananda: I dislike 1
19:17:26 <lifeless> devananda: I think either way is fine, as long as vendors never need to change ironic [past our early teething issues]
19:17:29 <JimJiang> i like 2
19:17:30 <martyntaylor> devananda: because its very RPC
19:17:58 <lifeless> in terms of making a decision, I suggest using the PXE callback as a brilliant example, because that is a vendor extension
19:18:15 <lifeless> it just happens to be one we'll need upstream, because PXE as a whole is upstream
19:18:26 <devananda> right
19:18:40 <lifeless> if the PXE callback is going to work well, then the decided strategy will work well :)
19:19:10 <devananda> so, since RPC between API and Manager is versioned, and we are expressly stating that vendor extensions shouldn't require code _in_ ironic (aside from the general enabling of extensions)
19:19:22 <devananda> this means we will need a single generalizable RPC call for _all_ vendor extensions
19:19:25 <martyntaylor> lifeless: I don't quite understand the use case for PXE would you be able to write it up/explain
19:19:51 <devananda> lifeless: want me to field that question?
19:20:41 <lifeless> devananda: sure
19:20:50 <devananda> martyntaylor: PXE deploy (as we do it today) requires an unusual callback
19:21:25 <martyntaylor> call back to who and what for?
19:21:34 <devananda> martyntaylor: after the Manager has deployed the initial image, it performs some work,but will need to posts data back to the Manager for subsequent work
19:21:51 <lifeless> martyntaylor: the deployramdisk does^ not the tenant image.
19:22:04 <devananda> that's not really part of telling ironic "deploy this image here", but an implementation detail in the PXE driver
19:22:11 <martyntaylor> sure
19:22:21 <martyntaylor> and i suppose this can happen under the covers of the API?
19:22:26 <devananda> that's the plan
19:22:31 <martyntaylor> the PXE driver can call the manager direct
19:22:32 <martyntaylor> sure
19:22:40 <devananda> in nova-baremetal, it is a separate service, which has led to a lot of issues
19:22:53 <lifeless> it could, but then you need a new listening port in the manager
19:23:43 <devananda> either: deploy ramdisk calls to a separate service, or it makes RPC call to manager, or it calls to the public API
19:23:44 <martyntaylor> right
19:24:06 <lifeless> putting deploy ramdisk on the message bus is a huge security risk, so lets rule that out
19:24:16 <devananda> rather than creating additional services, or embedding an AMQP client and all that entails in a minimal ramdisk, and all ^ security isses
19:24:33 <devananda> lifeless and I both feel a POST to the public API is best
19:24:45 <martyntaylor> got it
19:24:48 <devananda> that's not part of the normal driver requirements, though
19:24:52 <martyntaylor> sure
19:25:00 <devananda> so it's a good test bed for driver/vendor extensions
19:25:00 <devananda> :)
19:25:07 <martyntaylor> sure
19:25:13 <JimJiang> It's right
19:25:40 <martyntaylor> devananda: so again with this stuff, I'd still like to suggest we represent vendor actions as resources, like a job or whatever
19:26:03 <martyntaylor> devananda: this keeps the API consistent and still ReSTful
19:26:28 <martyntaylor> devananda: I think this is where we left our discussion last Friday
19:26:48 <martyntaylor> and its probably not good to bring it up here, since it;s probably my lack of understanding that was the cause of contention
19:27:26 <devananda> taking the PXE situation as an example
19:27:33 <devananda> what will be POSTed back is not job-like
19:27:44 <devananda> but a new resource
19:28:08 <martyntaylor> right
19:28:11 <lifeless> martyntaylor: so I don't think we should /care at all/ about whether the vendor API is restful.
19:28:28 <martyntaylor> will it not be consumed by end users?
19:28:29 <lifeless> martyntaylor: I think vendors should be able to make it restful, and be encouraged, but not constrained.
19:28:34 <martyntaylor> ok
19:28:35 <lifeless> martyntaylor: hell no.
19:28:58 <martyntaylor> ah
19:28:59 <lifeless> martyntaylor: by definition it is vendor specific; this falls into three categories IMO:
19:29:24 <lifeless> - things like the PXE example - plumbing needed to make a driver work. E.g. $vendor appliance needs to tell ironic's vendor-driver something.
19:30:05 <lifeless> B - things for the cloud admin to use that the $vendor-driver enables [e.g. firmware magic or something we haven't standardised]
19:30:12 <martyntaylor> right
19:30:28 <martyntaylor> lifeless: ok sure, so please don't let me hog the meeting getting you guys to explain stuff
19:30:35 <lifeless> C - things for $vendor-other-product to use to poke at $vendor-driver internals.
19:30:49 <lifeless> A and C are kindof similar
19:30:53 <martyntaylor> got it
19:31:12 <lifeless> B you may well want to make restful and fully self documenting yada yada yada, but IME vendors will want to write their own CLI or GUI for that stuff anyhow.
19:31:19 <martyntaylor> sure
19:32:04 <lifeless> martyntaylor: anyhow, thats why I don't care about restful in the vendor API: the goal IMNSHO is to make it not-our-problem
19:33:08 <JimJiang> implement the extension mode same in nova?
19:33:48 <lifeless> devananda: sorry, I'm typing way to much :)
19:33:55 <devananda> JimJiang: AIUI, nova's API extensions require in-tree code, at leat for v2, which led to a lot of cruft and headache for other virt drivers
19:34:04 <devananda> lifeless: NP! thanks for jumping in and clarifying
19:34:14 <lifeless> JimJiang: can you give a quick overview on how that works? Do vendors have to change the nova tree when they want a new extension?
19:34:20 <devananda> martyntaylor: hopefully this ^ has helped clear up the discussion from late friday?
19:34:30 <lifeless> JimJiang: how does it split stuff between API server and compute node, or scheduler node?
19:35:01 <martyntaylor> devananda: absolutely lifeless devananda thanks for the explaination
19:37:10 <devananda> JimJiang: ?
19:37:39 <devananda> ok, we can come back to that when he's back
19:37:53 <devananda> actually i think that was the last thing on the agenda
19:37:56 <devananda> #topic open discussion
19:38:28 <devananda> anyone / anything else? :)
19:38:59 <linggao> how do we test the ironic code?
19:39:01 <NobodyCam> wanted to say good Job to devananda and lifeless on the vendor passthru
19:39:16 <devananda> linggao: right now, unit tests is all we have.
19:39:40 <linggao> does it requires other components like cinder, nova?
19:39:45 <devananda> linggao: there isn't enough yet to stand up a full ironic platform and test a deployment
19:40:12 <devananda> linggao: it will, yes. glance for image service, quantum for networking
19:40:56 <devananda> linggao: nova will be used for scheduling, though i think it will be possible to use without nova
19:41:20 <devananda> ah. nova will also be used for cloud metadata service
19:41:34 <linggao> a stupid question, what do you use to do unit test?  nodetests?
19:41:46 <linggao> nosetests? pytest?
19:42:04 <devananda> #link http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html
19:42:12 <devananda> linggao: that ^ should help get you started with unit testing
19:42:52 <linggao> cool. thanks. I just want to set up my env so that I can start contribute some code.
19:43:00 <devananda> great :)
19:43:14 <NobodyCam> linggao: if you have any questions hit us up in #openstack-ironic after the meeting
19:43:33 <linggao> sure, I will. thanks
19:44:21 <devananda> if there's nothing else, i'll wrap up a bit early today
19:44:28 <NobodyCam> :)
19:45:02 <devananda> ok, thanks everyone!
19:45:08 <devananda> #endmeeting