19:00:45 <devananda> #startmeeting ironic
19:00:45 <mrda> \o
19:00:46 <openstack> Meeting started Mon Oct 20 19:00:45 2014 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:47 <JayF> o/
19:00:47 <dtantsur> o/
19:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:49 <NobodyCam> \o/
19:00:49 <lucasagomes> o/
19:00:51 <openstack> The meeting name has been set to 'ironic'
19:00:52 <adam_g> o/
19:00:56 <rloo> o/
19:00:56 <linggao> \o
19:01:09 <mjturek> \o
19:01:12 <wanyen> hi
19:01:45 <devananda> as usual, our agenda can be found on the wiki, but actually, today I'd like to just go over the summit plans for most of the time
19:02:11 <devananda> I sent an email to the list this morning about that
19:02:13 <NobodyCam> #link https://docs.google.com/spreadsheets/d/1XBKdeDeGfaRYaThjIIoYRwe_zPensECnxsKUuqdoVmQ/edit#gid=101783491
19:02:39 <GheRivero> o/
19:03:03 <NobodyCam> love the pinky and brain link
19:03:16 <devananda> #topic summit planning
19:04:13 <devananda> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/048777.html -- for those who didn't see the email this morning
19:04:34 <devananda> short version is, we had 30 proposed topics
19:04:39 <devananda> a lot of similarities between some of them
19:04:48 <NobodyCam> awesome :) thank you all
19:05:04 <devananda> please look at the second tab in the spreadsheet NobodyCam linked and let's discuss
19:05:31 <jroll> devananda: the nova section, are those the topics nova picked or that we want to chat with nova about?
19:05:42 <devananda> jroll: sort of both?
19:05:58 <devananda> jroll: nova hasn't set their sechedule yet either, but they are discussing it on an etherpad -- https://etherpad.openstack.org/p/kilo-nova-summit-topics
19:06:09 <jroll> devananda: ok
19:06:10 <devananda> jroll: so those things on our spreadsheet are things I think we should talk with them about
19:06:25 <NobodyCam> devananda: are the open ended question from us to the Ops or from the Ops to us?
19:06:27 <jroll> I want to chat about cached images again, but I know it's low priority
19:06:32 <devananda> jroll: if they have a full session on anything, it would probably be clustered hypervisor and/or driver split
19:06:41 <devananda> NobodyCam: us to ops. as a way to elicit feedback
19:06:50 <devananda> jroll: cached in what respect?
19:07:07 <jroll> devananda: pre-imaging things
19:07:16 * NobodyCam revives his generate question task
19:07:21 <jroll> like they discussed in ATL
19:07:40 <devananda> jroll: oh. pre-deploying common images to nodes
19:07:46 <devananda> jroll: that goes a step beyond just ready-state
19:08:07 <jroll> devananda: right, this is just something on my mind lately, don't mind me :)
19:08:24 <devananda> jroll: I think the general case of that is worth discussing -- keeping a pool of nodes in "ready-state" based on some awareness of what users want
19:08:31 <jroll> +1
19:08:33 <lucasagomes> I think by ready-state we mean having all the physical characterists of the node already "discovered"
19:08:40 <lucasagomes> right?
19:08:49 <devananda> lucasagomes: not just discovered, no, but actually set in the appropriate way
19:09:00 <devananda> lucasagomes: firmware updated, BIOS settings tuned for a specific worklaod, RAID built, etc
19:09:09 <devananda> all the things that come before "put an image down and boot it"
19:09:09 <lucasagomes> oh, right interesting
19:09:17 <lucasagomes> gotcha
19:09:35 <devananda> anyone who hasn't should go read zehicle's blog on ready-state
19:09:52 <lucasagomes> link?
19:09:52 <devananda> zehicle == rob hirschfeld
19:10:00 <jroll> link?
19:10:21 <lucasagomes> #link http://robhirschfeld.com/2014/04/25/ready-state-infrastructure/
19:10:29 <jroll> thanks
19:10:34 <devananda> yep
19:10:37 <devananda> was just lookin for it
19:10:58 <devananda> I may not agree with everything there, but as a basis for discussion and terminology, it's not terrible
19:12:00 <lucasagomes> devananda, things like json patch diff for our library, do we need a discussion on that? I think it's a nice feature I would argue that we could just propose a patch for it and discuss in gerrit if needed
19:12:16 <rloo> devananda: how do we get the initiatives/goals for the 4th session? or is it in that session where the initiatives/goals are decided?
19:12:55 <lucasagomes> rloo, maybe we should start an etherpad about it
19:12:56 <devananda> lucasagomes: totally agree. if that's not already proposed by the summit, I think it might be fun to hack on it together
19:13:02 <dtantsur> lucasagomes, ++ not the thing to have a holy war on :)
19:13:06 <lucasagomes> so we can put the ideas there
19:13:16 <lucasagomes> devananda, sounds good
19:13:17 <lucasagomes> dtantsur, ++
19:13:29 <devananda> rloo: we look at open specs, the list of blueprints, and ideally create an etherpad ahead of time :)
19:13:53 <devananda> dtantsur: let's try not to have holy wars in general :)
19:13:56 <rloo> devananda: ahh, thx.
19:14:05 <devananda> as far as the topics for the 5 sessions I've proposed - does anyone feel that one of those topics doesn't warrant a whole slot?
19:14:24 <devananda> or a slot would be better served with a different topic?
19:14:45 <rloo> where did you hide 'discovery'?
19:14:54 <devananda> also - in case anyone wonders how I grouped my thoughts on this, I used https://etherpad.openstack.org/p/mk2Fhb2sXe as a scratch pad
19:15:35 <lucasagomes> rloo, I think it goes on the ready-state, but... hmm differently than discovering a node that is not yet registered in Ironic
19:15:39 * NobodyCam was going ask how testing and stand-alone usage got grouped
19:15:50 <devananda> rloo: if by "discovery" you mean "discover unknown nodes" - I think there's been agreement that is out of bounds.
19:16:03 <devananda> rloo: if you mean "introspection", then that could fall under ready-state or under capabilities
19:16:08 <devananda> since it has ramifications for both
19:16:31 <dtantsur> devananda, I think everyone uses "discovery" as you use "introspection" now
19:17:07 <devananda> dtantsur: there was at least one proposal in Juno that used it to mean "find unknown nodes", so I've tried to stick with separate words ...
19:17:19 <dtantsur> devananda, it was mine and I changed my mind :)
19:17:36 <lucasagomes> the 3 empty slots on the hacktathon, I would like to add the idea of having a stateless iPXE driver there
19:17:36 <dtantsur> devananda, so I allow everyone to no longer use discovery in that sense :D
19:17:41 <lucasagomes> can I?
19:17:46 <rloo> devananda: ok thx. I think I was thinking that the 'decom' part would take the most time, and not much time for 'ready-state', but we'll see.
19:17:47 <jroll> lucasagomes: ++
19:17:52 <devananda> dtantsur: I think there was also one from HP. but anyway, I'll happily start using discover-capabilities
19:18:06 <dtantsur> lucasagomes, +many
19:18:08 <devananda> lucasagomes: oh! the hackathon is unstructured -- you can add as many slots as you want there
19:18:17 <devananda> lucasagomes: keeping in mind that it'sonly a half day
19:18:20 <lucasagomes> awesome, added!
19:18:39 <lucasagomes> right, I will try to put the ideas in a organized way on an etherpad before
19:18:40 <devananda> lucasagomes: also, stateless iPXE driver ++
19:18:44 <lucasagomes> to save some time
19:18:45 <rloo> lucasagomes: what's there to discuss? or are you going to code it there? :-)
19:19:34 <JayF> lucasagomes: stateless ipxe driver is the carrot to get us to use something other than our static configs all the time :P
19:19:46 <devananda> in general, if we can simply resolve something with a spec and some code, it probably doesn't need to take up f2f time in a scheduled slot
19:20:14 <lucasagomes> rloo, hah both maybe... I was mostly thinking about showing the idea, and starting a discussion from there
19:20:24 <devananda> the things I've tried to put in the meetup area are either a) things we aren't sure how we want to proceed and probably need to grab someone from another team to sort out (like infra, or nova, or oslo)
19:20:25 <rloo> devananda: the 2nd part 'stand-alone usage' (5th session), what did you mean by that? Tests for that?
19:20:46 <lucasagomes> JayF, ++
19:20:55 <lucasagomes> rloo, I think it's about removing dependencies like we did for neutron
19:21:06 <lucasagomes> rloo, or e.g glance, why we cna't just point to a path on the fs with the images
19:21:17 <lucasagomes> instead of having to use glance to provide the image for us
19:21:19 <NobodyCam> what deps do we have glance?
19:21:42 <devananda> NobodyCam: glance across the board. neutron if you have local state. swift for both IPA and iLO drivers.
19:21:44 <lucasagomes> NobodyCam, we always fetch the images from glance today
19:21:44 <jroll> swift for certain drivers
19:22:00 <rloo> lucasagomes: ah, ok, ironic stand-alone w/o other openstack components.
19:22:00 <NobodyCam> ack
19:22:01 <lucasagomes> yeah and swift
19:22:09 <lucasagomes> rloo, that's my understanding
19:22:20 <devananda> as far as stand-alone, yes, I mean that, but also
19:22:36 <devananda> our API is not very straight forward to use without Nova, at least with the PXE driver
19:22:49 <lucasagomes> ++
19:22:56 <JayF> devananda: note: the ready-state and decom phase thing is scheduled for *before* the decom talk me and Josh are giving
19:23:06 <JayF> devananda: I'd suggest pushing that to the slot first thing Thursday, if possible
19:23:07 <devananda> JayF: ooh. right, good point
19:23:16 <lucasagomes> we have to do things like setting the instance_uuid to deploy a node, even if we don't use nova
19:23:24 <wanyen> what the use cses for standalone ironic?  I meant why to user ironic stanalone?
19:23:33 <rloo> shouldn't the progress retro & goal setting be at the end?
19:23:48 <jroll> I want to use ironic standalone for functional testing, personally
19:24:00 <mrda> Should we also reference the Ironic-related summit talks in that etherpad?
19:24:14 <jroll> mrda: they're in the last tab of the google doc
19:24:14 <wanyen> jroll: ah.  for testing.
19:24:22 <jroll> wanyen: there are other use cases :)
19:24:29 <jroll> that's just mine
19:24:39 <mrda> jroll: thanks (-ESTILLASLEEP)
19:24:42 * devananda moves things around
19:24:43 <lucasagomes> wanyen, but also I think it's based on some people that has a very small number of machines and they just want to deploy a image to it w/o having to deploy multiple os components
19:24:51 <jroll> think about tripleo; it would be great if they could use just ironic and not bother with setting up all of openstack
19:25:01 <devananda> mrda: they are linked on the third tab
19:25:12 <NobodyCam> jroll: ++++++++++!
19:25:14 <mrda> devananda: thanks
19:25:25 <rloo> jroll: does it become double-o then :-)
19:25:48 <jroll> rloo: I don't care :) OOI, I guess
19:25:59 <devananda> jroll: not exactly - tripleo actually relies on other components of openstack for the lower layers too, eg. scheduling, resource placement, and networking
19:26:27 <wanyen> lucasagomes: tx
19:26:33 <jroll> devananda: ok, a version of tripleo that doesn't care about that, idk, I'm just making stuff up
19:26:35 <rloo> devananda: how much or what xproject stuff on tues might/could over functional testing?
19:26:42 <rloo> s/over/cover
19:26:50 <jroll> devananda: I'm thinking "deploy 10k nova-compute hosts to an existing cloud" :)
19:26:57 <devananda> rloo: i have no idea right now. possibly a lot, since that is the cross-project day
19:27:22 <devananda> rloo: I think I see why you ask -- it's possible we'll get all we need from those and NOT need our own session on it
19:27:34 <NobodyCam> jroll: to an existing cloud(or infrastructure) is questions I have gotten before
19:27:40 <wanyen> lucasagomomes: sorry I clicked on  your name by accident it shows your info.
19:27:59 <rloo> devananda: yes, that's what i was thinking. OTOH if a lot of it is covered on tues, the session could be a good recap/get into details about the changes for ironic.
19:28:07 <lucasagomes> wanyen, it's all good :) it only appears on ur client
19:28:18 <rloo> and then more time for people to ask why a stand-alone ironic ;)
19:28:18 <devananda> rloo: that's what I'm hoping for - getting into the details of what we want to accomplish in Kilo
19:28:33 <devananda> as far as changes to our testing, tempest jobs, etc
19:28:57 * rloo hopes adam_g and Shrews will be there
19:29:10 * Shrews will not be in Paris
19:29:16 <adam_g> ill be there
19:29:18 <NobodyCam> :(
19:29:21 * devananda updates the session description
19:29:33 * rloo is somewhat happy
19:29:41 <lucasagomes> Shrews, oh noes :(
19:31:00 <devananda> do we see discovering hardware properties as something that can fit into the ready-state discussion?
19:31:05 <devananda> or realy worth a separate slot?
19:31:23 <jroll> I think it fits; I don't think we'll have time
19:31:27 <lucasagomes> I was thinking it fits
19:31:36 <NobodyCam> devananda: that will be one of our more contenious topics
19:31:47 <NobodyCam> I would vote for a whole slot
19:31:56 <dtantsur> I'm always for discussion discovery :)
19:31:59 <jroll> I vote for L :P
19:32:28 <rloo> jroll: 'L'?
19:32:38 <jroll> rloo: L cycle
19:32:49 <jroll> rloo: but I just tend not to care too much about discovery :)
19:33:00 <devananda> JayF: are you going to cover discovery at all in your talk on wed. afternoon?
19:33:09 <rloo> jroll: hmm, I think you have to vote in the kilo goal setting session then ;)
19:33:13 <JoshNang> devananda: not planning on it
19:34:03 <jroll> ha
19:34:06 <devananda> hmm
19:34:14 <lucasagomes> jroll, based on previous summits there's a bunch of ppl interested in discovery, I would like to see it included in K
19:34:21 <jroll> devananda: we don't do discovery downstream...
19:34:32 <jroll> lucasagomes: yep, just my opinion
19:34:33 <devananda> jroll: gotcha. you trust your inventory db?
19:34:38 <devananda> JayF and I were talking about this last week
19:34:47 <jroll> devananda: no, we don't trust it :)
19:34:47 <lucasagomes> jroll, sure :) it's all good
19:34:48 <devananda> wanting to know when hardware ceases to match what your inventory record of it is
19:34:57 <wanyen> I am intersted in discovery-hw-properties discussion
19:35:01 <jroll> devananda: we've started playing with verifying what ironic knows vs reality
19:35:10 <devananda> jroll: so when do you re-check whether a node ... right, that "verification"
19:35:17 <JoshNang> ^ verifying is hard
19:35:18 <jroll> yeah, gotcha
19:35:28 <devananda> that's different from discovering what 's there when you know nothing but IPMI creds
19:35:45 <devananda> functionally the same process, but different use case
19:35:59 <jroll> right
19:36:01 <devananda> and definitely something everyone has been interested in for a while
19:36:17 <devananda> I'm starting to think it's worth a separate slot
19:36:32 <NobodyCam> ++
19:36:42 <wanyen> ++
19:36:44 <lucasagomes> heh yeah it looks like now
19:37:10 <NobodyCam> I think just a general introspection vs discovery conversation will take up a fair amount of time
19:37:33 <rloo> what/how much time do you think 'decom' will take?
19:37:52 <NobodyCam> rloo: who is that too?
19:38:04 <devananda> I am hoping/expecting that all of us will attend JayF's and JoshNang's talk on decom
19:38:06 <rloo> NobodyCam: huh?
19:38:11 <JoshNang> :)
19:38:22 <devananda> so we don't need to talk about what it is, and instead can talk about how we generalize it
19:38:25 <wanyen> is decom a seperate session or is it part of the ready state?
19:38:26 <rloo> devananda: yeah. So I was wondering (sorry Js) whether we needed decom in a session
19:38:39 <NobodyCam> rloo: : how much time do you think 'decom' will take? who was that addressed to?
19:38:52 <rloo> NobodyCam: whoever was going/talking about decom
19:38:55 <JoshNang> I think decom will be fairly contentious. it's complex to support in the general state, with a lot of possible directions
19:39:00 <devananda> wanyen: decom and ready-state should be one session IMO
19:39:15 <devananda> because they are addressing the same use case
19:39:30 <NobodyCam> devananda: I agree
19:39:31 <JoshNang> +1
19:39:31 <devananda> "get a node into a state where it is ready to be provisioned"
19:39:56 <devananda> whether that is a new node or a node just returned to the pool doesn't matter -- it's just different entry points into the same flow, as it were
19:40:11 <devananda> *different reasons
19:40:25 <wanyen> deva, that's fine.  we might want to consider naming decom to ready state?
19:40:39 <devananda> wanyen: ++
19:40:45 <devananda> JayF, JoshNang ^
19:40:46 <lucasagomes> that's a good point
19:40:49 <NobodyCam> i'd be good with that
19:41:21 <JayF> I don't mind that at all, as a concept
19:41:30 <JayF> we always viewed decom as something that was the "first" step, not the "last" step anyway
19:41:30 <devananda> ok, so we're still left with a desire for a discussion around discovery and no slot for it ...
19:41:43 <devananda> what gets moved?
19:42:51 <devananda> retrospective and goal setting is lowest on my list
19:42:56 <rloo> can we do the retrospective via email?
19:42:58 <JayF> stand-alone ironic?
19:42:59 <lucasagomes> hmm the retrospective needs to be an official slot? can't be something in the contributor meetup?
19:43:02 <NobodyCam> thats what I was just looking at
19:43:12 <mrda> lucasagomes: +1
19:43:15 <devananda> we already have a process for doing that via specs and launchpad
19:43:19 <JayF> I think that's likely to have the most amount of movement without having f2f conversation
19:43:24 <devananda> a discussion in the meetup might still be good
19:44:01 <lucasagomes> yeah cause retrospective is good, but won't generate much discussion (I guess) so we can move it to the end of the day friday
19:44:02 <devananda> JayF: that's also a good point
19:44:10 <jroll> ++ for friday
19:44:13 <wanyen> I think tehra are many folks interested in  instrospection - discover hw properties so it deserves a session
19:44:38 <rloo> retrospective: we wanted introspection and we still haven't gotten it yet :-)
19:44:56 <NobodyCam> rloo: lol
19:44:56 <devananda> rloo: LOL
19:45:24 <lucasagomes> lol
19:46:08 <jroll> can I go off topic for a moment? is anyone interested in moving the time of this meeting? (probably to something earlier). this is pretty late for european folks and during tech talks / lunch for us rackspace people
19:46:26 <mrda> or later :)
19:46:27 <rloo> the most useful thing from retrospective, is if there are things that we can improve on, that we might want to discuss f2f. but ... something has to give. maybe we can start that via email before, and then meet like lucas suggested, on fri
19:46:28 <jroll> not sure what's available but would love to eat lunch away from my laptop on mondays :)
19:46:36 <jroll> mrda: oh yeah, there's you...
19:46:39 <jroll> :P
19:46:40 <devananda> jroll: I'm fine with that. also, it's going to change to an hour earlier for US folks because of DST
19:46:51 <devananda> if there are no more comments on the schedule ...
19:46:57 <rloo> jroll: but if you make it earlier, it means mrda has to get up earlier
19:47:05 <jroll> devananda: oh, right, that will satisfy me enough. leave it to everyone else, then :)
19:47:09 * jroll forgot about DST
19:47:17 * jroll hates timezones
19:47:44 <lucasagomes> :D
19:47:50 <mrda> jroll: Just work in GMT+9.5 and we'll all be happy :)
19:47:59 <jroll> nonono, work on utc
19:47:59 <NobodyCam> I'm good with the schedule changes we've come up with here
19:48:08 <devananda> thanks, everyone, for the feedback on scheduling for the summit
19:48:26 <NobodyCam> FYI 12 minutes left
19:48:31 <devananda> #topic open discussion
19:48:35 <rloo> and those Js can even skip the introspection session ;)
19:48:47 <jroll> ha, no!
19:49:01 <devananda> one question for folks -- should we have a meeting next week? (last one before the summit)
19:49:13 <rloo> oh wait, you want to change it to 11 wed instead? (I forgot which time wasn't good for the Js)
19:49:13 <jroll> I don't see why not
19:49:16 <lucasagomes> I don't see why not
19:49:20 <lucasagomes> jroll, + heh
19:49:23 <jroll> rloo: all times are fine for us
19:49:26 <devananda> k
19:49:33 <jroll> talks were moved
19:49:39 <rloo> but skip the meeting after the summit
19:49:43 <NobodyCam> I would lets have a meeting but try and keep it focused on summity things
19:49:54 <devananda> fwiw, i'll be flying to paris on tuesday, so semi-offline for most of the week prior to the summit
19:49:59 <NobodyCam> as this one has been
19:50:03 <adam_g> i will not be around next week, will be offline this wednesday to next wednesday
19:50:03 <devananda> NobodyCam: ++
19:50:19 <jroll> I'll be gone the week after the summit :)
19:51:09 <devananda> anyone have other topics to bring up?
19:51:11 <lucasagomes> I'll be there sunday afternoon, if someone wants to catch up for some drinks
19:51:33 <mrda> lucasagomes: +1
19:51:48 <devananda> lucasagomes: I'll be in a board meeting / dinner sunday -- ya'll should definitely get together though!
19:51:48 <dtantsur> lucasagomes, +1
19:51:49 <NobodyCam> oh also for open discussion... congratz to jroll for landing the first Kilo Spec
19:52:04 <mrda> lucasagomes: Sunday afternoon for something Ironicly informal would be nice
19:52:07 <devananda> lucasagomes: so feel free to organize that
19:52:18 <jroll> hehe
19:52:24 <mrda> jroll: good job!
19:52:25 <lucasagomes> right!
19:53:22 <devananda> which reminds me, I had suggested we have an informat get-together at some point
19:53:23 <lucasagomes> ok we have 7 minutes... are you guys OK in extending the [driver_]vendor_passthru to support other HTTP methods?
19:53:31 <lucasagomes> if so do I need to write a spec for it or a bug would be enough?
19:53:51 <NobodyCam> lucasagomes: you want GET?
19:53:51 <devananda> lucasagomes: broadly speaking, I don't think I'm OK with that yet
19:54:06 <lucasagomes> NobodyCam, yup, I need it for the iPXE driver
19:54:12 <lucasagomes> devananda, right, reasons?
19:54:24 <devananda> lucasagomes: because a synchronous GET seems crazy to me
19:54:41 <devananda> until we actually have a means for a fully asynch API, I don't think we can support that
19:54:42 <lucasagomes> devananda, when it talks to the BMC right?
19:54:48 <devananda> lucasagomes: right
19:54:55 <lucasagomes> but not always that's the case
19:55:00 <devananda> but opening that up in the API enables it
19:55:04 <jroll> as long as it doesn't talk to the bmc, should be fine
19:55:09 <jroll> driver_vendor_passthru is already sync
19:55:11 <devananda> even if you might not implement it, the API is there for someone else to do so
19:55:16 <jroll> like, document it and move on
19:55:25 <devananda> jroll: that doesn't have a node reference
19:55:25 <jroll> we'll catch that sort of thing in code review
19:55:33 <lucasagomes> devananda, right, but that's something that we can't document right? I mean we can advise people to not use it to talk to the BMC
19:55:38 <devananda> jroll: we don't get to review all the drivers. some exist downstream
19:55:40 <lucasagomes> devananda, and use async POST for e.g for that
19:55:51 <jroll> devananda: POST /drivers/whatever/vendor_passthru {'method': 'ping_all_the_bmcs'}
19:56:00 <devananda> jroll: also, documentation is something we're sorely lacking right now, IMHO
19:56:11 <jroll> devananda: sure, but we can't like, not allow cool things to happen because someone might shoot themselves in the foot
19:56:23 <lucasagomes> +1
19:56:25 <dtantsur> devananda, I'm not sure we can hold responsibilities for every crazy thing that might happen downstream
19:56:26 <devananda> lucasagomes: what's the example where you need this?
19:56:29 <jroll> asynchronous GET sounds absolutely absurd to me
19:56:38 <lucasagomes> devananda, to generate the pxe config files
19:56:41 <NobodyCam> oh documentation .. that sounds like a good hacking session
19:56:54 <lucasagomes> GET /v1/drivers/ipxe/<MAC>
19:56:57 <devananda> lucasagomes: generate them outside of ironic?
19:57:00 <bth-> g
19:57:01 <devananda> s/generate/store/
19:57:20 <lucasagomes> devananda, well but the idea is to get a pxe config file on the flight using some HTTP request
19:57:31 <lucasagomes> and ironic already has an api, so I would like to use it
19:57:46 <devananda> lucasagomes: ahh. gotcha
19:58:01 <NobodyCam> lucasagomes: maybe a spec would help
19:58:01 <lucasagomes> and in the ipxe script I would just do a: chain http://ironic-api/v1/driver/ipxe/<MAC>
19:58:10 <lucasagomes> and chainload to that
19:58:13 <lucasagomes> no BMC talk at all
19:58:16 <devananda> so GET /v1/drivers/ipxe/vendor_passthru?method=config&mac=NNNN
19:58:18 <devananda> something like that
19:58:26 <lucasagomes> exactly
19:58:54 <devananda> yea, I can totally see how that's useful
19:58:54 <lucasagomes> NobodyCam, right I will try to put something up soonish
19:59:03 <NobodyCam> :) awesome TY
19:59:16 <devananda> lucasagomes: spec would help describe the workflow, I think
19:59:16 <lucasagomes> devananda, right :)
19:59:28 <lucasagomes> devananda, I will put one up then
19:59:34 <jroll> one minute beep
19:59:37 <lucasagomes> I will continue on the channel
19:59:40 <NobodyCam> :)
19:59:48 <rloo> speaking of async, do we want to discuss async REST api at the summit? https://review.openstack.org/#/c/94923/
19:59:55 <jroll> thanks everybody :)
20:00:03 <devananda> rloo: that was on my list but got dropped ...
20:00:07 <devananda> rloo: so yes, but not in a slot
20:00:09 <NobodyCam> great meeting Thank you all
20:00:12 <devananda> anyhow, thanks everyone!
20:00:16 <mrda> thanks!
20:00:19 <rloo> devananda: ok
20:00:20 <devananda> #endmeeting