19:00:14 <NobodyCam> #startmeeting ironic
19:00:15 <openstack> Meeting started Mon Aug 19 19:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:18 <openstack> The meeting name has been set to 'ironic'
19:00:30 <NobodyCam> who's here for the iRonic meeting
19:00:34 <devananda> \o
19:00:37 <lucasagomes> :)
19:00:43 <linggao> me
19:00:51 <NobodyCam> :)
19:01:00 <NobodyCam> welcome all
19:01:16 <GheRivero> o/
19:01:34 <NobodyCam> ok first up. I've tried to keep the agenda a little more up to date.
19:01:44 <NobodyCam> Agenda can be found at: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
19:02:14 <NobodyCam> first up:
19:02:15 <NobodyCam> #topic testing env
19:03:02 <NobodyCam> # link https://review.openstack.org/#/c/41053/
19:03:07 <NobodyCam> for devstack
19:03:28 <NobodyCam> looks like its getting a bit closer
19:03:58 <NobodyCam> is Roman around?
19:04:05 <lucasagomes> he's on vacations no?
19:04:12 <NobodyCam> oh thats right
19:04:46 <NobodyCam> that brings us to the Dib element
19:05:16 <NobodyCam> I've got a couple of -1 (which I expected) that I have yet to address in the reviews
19:06:00 <NobodyCam> I have addressed most of the issues in my (/nobodycam/) repo but have not pushed up the changed for review
19:06:10 <NobodyCam> I will get to that this week
19:06:32 <NobodyCam> any questions or comments?
19:06:45 <lucasagomes> the link for the repo u've the changes
19:06:47 <lucasagomes> is this one? https://github.com/NoBodyCam/ironic-element/
19:07:06 <NobodyCam> yep thats the one
19:07:15 <NobodyCam> #link https://github.com/NoBodyCam/ironic-element/
19:07:42 <NobodyCam> I will add that link to my notes on the agenda
19:07:58 <NobodyCam> #topic in-progress tasks
19:08:05 <NobodyCam> so moving on
19:08:19 <NobodyCam> un less there are more questions
19:08:46 <NobodyCam> Keystone authentication.
19:08:59 <NobodyCam> *admin-only done. v3 domains not working yet
19:09:08 <NobodyCam> any updates here?
19:09:44 <devananda> romcheg was working on that, iirc
19:10:11 <NobodyCam> ya so I think we're on hold till he get back :)
19:10:22 <NobodyCam> next up a biggie: PXE driver
19:10:30 <NobodyCam> image services patch LANDED! 35272
19:10:33 * GheRivero yes yes yes!
19:10:50 <GheRivero> not where we like it, but it's there
19:10:54 <NobodyCam> #link https://review.openstack.org/#/c/35272/
19:11:08 <NobodyCam> Ghe awesome job getting that thru
19:11:15 <NobodyCam> several false starts
19:11:29 <NobodyCam> but great patch
19:12:05 <NobodyCam> # link https://review.openstack.org/#/c/33616/
19:12:12 <NobodyCam> #link https://review.openstack.org/#/c/33616/
19:12:34 <NobodyCam> I've got a -1 on the last version but really for minor doc string stuff
19:13:14 <NobodyCam> any questions / comments for Ghe?
19:13:30 <devananda> i'll review that right after the meeting
19:13:36 <lucasagomes> I've to review that patch, will try to find a time to do it tomorrow
19:13:49 <NobodyCam> :) Thnk you !!!
19:14:03 <GheRivero> cool, waiting for it
19:14:06 <devananda> landing and testing the PXE driver patch is going to be a really big step closer to ironic being usable
19:14:18 <NobodyCam> devananda: ++++
19:14:22 <lucasagomes> indeed
19:14:35 <NobodyCam> o next up: IPMI name conflict with python-ipmi
19:15:03 <devananda> name conflict is almost resolved. the -infra team has been renaming a few repos over the last week
19:15:07 <NobodyCam> jbjohnso and mordred have been working on this onw
19:15:13 <devananda> :)
19:15:28 <NobodyCam> #link https://review.openstack.org/#/c/41086/
19:15:45 <NobodyCam> #link https://review.openstack.org/#/c/42503/
19:16:36 <NobodyCam> ok with out questions we'll move on.
19:16:47 <NobodyCam> recursive-driver-import problem! (FIXED)
19:17:12 <NobodyCam> #link https://review.openstack.org/#/c/39617/
19:17:13 <NobodyCam> Awesome fix devananda
19:18:17 <NobodyCam> any questions / comments for devananda (while he's still here, if only in body)
19:18:27 <NobodyCam> LOL
19:18:30 <devananda> :p
19:18:48 <NobodyCam> ok then moving on.
19:18:50 <NobodyCam> #topic API
19:19:10 <NobodyCam> nested objects
19:19:18 <NobodyCam> and
19:19:26 <NobodyCam> sub resources
19:19:42 <NobodyCam> do we have any q/c on these
19:19:53 <lucasagomes> it was about having a subresource of the subresource? something like nodes/state/power ?
19:19:55 <NobodyCam> (do we need to keep them on hte agenda?)
19:20:03 <lucasagomes> if so I found a way to do it with wsme/pecan
19:20:06 <devananda> nested objects - i think that's done
19:20:13 <devananda> eg, chassis/123/nodes
19:20:16 <lucasagomes> it's on the 40844
19:20:18 <lucasagomes> #link https://review.openstack.org/#/c/40844/
19:20:38 <NobodyCam> :)
19:20:39 <lucasagomes> ok yea it's done :)
19:20:53 <NobodyCam> ok I'll revove for next meeting
19:21:02 <NobodyCam> now!
19:21:14 <NobodyCam> our epic: PUT vs PATCH in the API
19:21:21 <lucasagomes> yea epic saga
19:21:22 <lucasagomes> soooo
19:21:33 <lucasagomes> tl;dr PUT is really confusing
19:21:45 <lucasagomes> it says you have to update the whole document but I couldn't figure out if that includes the server-generated stuff like the links
19:21:46 <devananda> looks like another rev of 40844 is up, i need to review that today too :)
19:22:02 <NobodyCam> #link https://review.openstack.org/#/c/42690/
19:22:04 <lucasagomes> So I entered the grey zone of the unclear usage of PUT, idk if it is or not allowed by the HTTP specification to do this full-but-yet-partial-update using PUT.
19:22:17 <lucasagomes> For what I read some ppl say yes and some ppl say no
19:22:34 <mordred> NobodyCam: what did I do?
19:22:36 <lucasagomes> and as what we want to have is partial updates I'm suggesting us to use use PATCH instead, which is not a lot of extra work since there's available libs to work with json-patch and it that was created to solve the problem  of the partial update.
19:22:54 <NobodyCam> lol mordred help with the python-ipmi rename!
19:22:59 <NobodyCam> TY mordred
19:23:00 <mordred> yay! that's done
19:23:08 <lucasagomes> so there's a patch in the gerrit now, implementing patch for the chassis and nodes resources
19:23:38 <lucasagomes> any thoughts?
19:23:52 <NobodyCam> mordred: was getting ppl to +1 your patch on same
19:24:06 <NobodyCam> lucasagomes: was that the link I just posted?
19:24:13 <lucasagomes> hmm
19:24:17 <lucasagomes> yea 42690
19:24:20 <lucasagomes> that's the one
19:24:23 <NobodyCam> :)
19:24:56 <devananda> ++ to PATCH
19:25:20 <NobodyCam> I was just about to say we really NEED both
19:25:21 <NobodyCam> put and patch
19:25:46 <lucasagomes> we will do PUT to update states for example... only when it makes sense to update the whole document
19:25:51 <devananda> at the moment, my addled brain thinks we need both, but for different things
19:26:15 <devananda> so we'll need to clearly lay out (in the API doc) which things should be updatd wqith PATCH and which with PUT
19:26:26 <devananda> and i feel like there is actually a good reason for the difference
19:27:37 <lucasagomes> just a note
19:27:43 <lucasagomes> glance uses patch to update the images
19:27:43 <NobodyCam> devananda: would you be able to add any thought you have to the ethier pad before you go?
19:27:43 <lucasagomes> http://docs.openstack.org/api/openstack-image-service/2.0/content/update-an-image.html
19:28:05 <NobodyCam> #link https://etherpad.openstack.org/IronicWhiteBoard
19:28:15 <NobodyCam> for those who don't have that link
19:28:22 <devananda> lucasagomes: exactly! POST = create an image. PATCH = update the image. PUT = create a tag on the image.
19:29:02 <devananda> so for us, POST might create a chassis, node, or port. PATCH would update the properties or driver properties of that thing. PUT would set specific things (states, for example)
19:29:18 <lucasagomes> :) +1
19:29:37 <NobodyCam> devananda: does lucasagomes example of do PUT to update states fit that model
19:30:27 <devananda> i need to re-review https://review.openstack.org/#/c/40844/8 after his last change
19:30:39 <NobodyCam> :)
19:30:59 <devananda> iirc, it modelled PUT well, but there was some feedback on the state's internal representations that looks like it has been incorporated
19:31:23 <lucasagomes> yea, there's many things yet to be done about the states
19:31:28 <devananda> yea
19:31:33 <lucasagomes> that review is more to expose it on the API
19:31:36 <devananda> i dont want us to nitpick the states too much in this patch
19:31:47 <NobodyCam> devananda: :)
19:31:56 <lucasagomes> the internals, how it will actually works, conditions etc still need to be coded
19:31:56 <devananda> because they /will/ evolve as we find edge cases, things we didn't think about, etc
19:32:02 <devananda> right
19:32:20 <NobodyCam> :)
19:32:44 <lucasagomes> yea, many corner cases, states will be something like
19:32:44 <lucasagomes> code first, document later
19:32:59 <NobodyCam> not to much later I hope
19:33:31 <lucasagomes> :D yea no, but we need to actually code and test in order to find all the conditionals, flaws etc
19:33:36 <NobodyCam> with out a working product doc are mainly what I reffer (myself and oters) to
19:34:22 <NobodyCam> :)
19:34:32 <lucasagomes> the doc can come in the same review as the commit if that's the case :)
19:34:53 <lucasagomes> what I mean is... it's hard to have the states in the specification before coding
19:34:58 <devananda> that's an interesting question, actually
19:35:06 <NobodyCam> lol .. U completely understand
19:35:15 <devananda> should the reviewers reject patches that change behavior (eg, API) if a doc change isn't included?
19:35:29 <devananda> (and with that, watch me derail the meeting :) )
19:35:36 <NobodyCam> lol
19:35:42 <lucasagomes> I usually do 2 commits, one for the doc and then one for the doc that depends on the code
19:35:49 <lucasagomes> I did it for the filtering
19:35:58 <NobodyCam> I actually planed for the put vs patch to be our longest section
19:36:01 <lucasagomes> but I don't mind in squashing it into 1 commit if that's the case
19:36:18 <lucasagomes> and then one for the code*
19:36:21 * lucasagomes tired
19:36:24 <NobodyCam> :)
19:36:51 <devananda> for inline docs, please do that in the same patch
19:37:06 <NobodyCam> devananda: ++
19:37:11 <lucasagomes> oh yea +1 on that
19:37:25 <devananda> for the sphinx docs, i can go either way, BUT, it's harder to enforce
19:37:32 <devananda> if it comes in a second patch
19:37:41 <devananda> and harder to review to ensure the doc change matches the code change
19:37:46 <NobodyCam> and takes more time to review
19:37:50 <NobodyCam> :)
19:38:06 <devananda> since we currently have developer docs in the same repo, i really don't see a good reason to do two patches
19:38:26 <devananda> at some point, we'll have to create deployer docs -- in the official openstack-docs repo(s). so that will have to be sseparate patch sets
19:38:51 <lucasagomes> I have no problem in doing in the same commit... I never got me thinking about it and the reasons posted here
19:38:55 <lucasagomes> sounds fair enough
19:39:00 <devananda> great, thanks!
19:39:15 <lucasagomes> so I think we can start -1 patches that changes things like the API and has no documentation
19:39:16 <NobodyCam> :)
19:39:39 <NobodyCam> devananda: want a #(action) for that :-p
19:39:52 <devananda> NobodyCam: nah. that's more of an informal vote
19:39:56 <NobodyCam> :)
19:40:07 <devananda> there is actually a formal vote mechanism, but i dont think we need to kick one off ...
19:40:13 <NobodyCam> ya
19:40:25 <lucasagomes> ok so we decided here
19:40:43 <lucasagomes> to go with PATCH and PUT
19:40:45 <NobodyCam> :) any thing else on this topic
19:40:55 <lucasagomes> and -1 reviews that changes things like API without docs
19:40:56 <NobodyCam> yes!
19:41:02 <lucasagomes> cool :)
19:41:10 <devananda> #agreed reviewers to start -1'ing patches that do not include doc updates
19:41:38 <NobodyCam> ok then moving on #topic FFT / open discussion
19:41:53 * NobodyCam notes fft = Food For Thought
19:42:04 <NobodyCam> just sometihng to keep in mind
19:42:31 <lucasagomes> where the vendor_passthru should actually live?
19:42:33 <devananda> #agreed use PUT and PATCH for the appropriate things. PUT = state changes, tags, etc. PATCH = change item(s) in a larger document (eg, driver properties)
19:42:39 <lucasagomes> /drivers/ or /nodes/
19:42:46 <lucasagomes> I dind't think much about it yet
19:42:59 <lucasagomes> anyone has something to say about it? is Yuri here?
19:43:15 <devananda> oh, just realized - NobodyCam - you didn't chair me, so my #agreed things propbably didnt count :)
19:43:23 <NobodyCam> ieek
19:43:28 <NobodyCam> #chair devananda
19:43:29 <openstack> Current chairs: NobodyCam devananda
19:43:36 <devananda> #agreed reviewers to start -1'ing patches that do not include doc updates
19:43:39 <devananda> #agreed use PUT and PATCH for the appropriate things. PUT = state changes, tags, etc. PATCH = change item(s) in a larger document (eg, driver properties)
19:43:42 <devananda> ty :)
19:43:47 <NobodyCam> :-p doh
19:44:04 <devananda> #topic open discussion
19:44:47 <devananda> lucasagomes: the first level of the path is specifying the type of thing being affected, ya?
19:45:00 <lucasagomes> yea
19:45:25 <devananda> lucasagomes: so i think that, when the pxe deploy ramdisk is sending data back, it should be sent to /nodes/123/vendor_passthru
19:45:36 <devananda> since it is first and foremost dealing with the deploy of a specific node
19:45:39 <lucasagomes> so I'm inclined to do it in the /nodes ... since it's says the "node" is deployed and things like that
19:45:43 <devananda> :)
19:45:55 <lucasagomes> yea... like that :)
19:46:12 <devananda> where i think we may eventually want /drivers/foo/vendor_passthru is for things like
19:46:54 <devananda> PUT {'action': 'discover', 'range': '192.168.100.0/24'} /drivers/ipmi/vendor_passthru
19:47:19 <NobodyCam> devananda: ++
19:47:36 <lucasagomes> indeed
19:48:02 <lucasagomes> also the format... I think you suggested 2 things before
19:48:30 <lucasagomes> POST {'method': 'noop', 'data': ... } /nodes/1/vendor_passthru
19:48:32 <lucasagomes> or
19:48:49 <lucasagomes> POST {'data': ... } /nodes/1/vendor_passthru/noop
19:48:55 <devananda> yea
19:49:10 <NobodyCam> lucasagomes: I like #2
19:49:14 <lucasagomes> where in the second case the /noop actually does not exists in the api code
19:49:23 <devananda> i dont have enough familiarity with other APIs to have an opinion on the interface
19:49:28 <lucasagomes> well I'd say #1 is easier
19:49:40 <lucasagomes> idk how to expose something that doesnt exist in the api
19:49:43 <devananda> i think we can implement #2 using Pecan's default handler
19:49:50 <lucasagomes> I can try to make a prototype
19:50:01 <lucasagomes> right
19:50:05 <devananda> #link https://pecan.readthedocs.org/en/latest/routing.html#falling-back-with-default
19:50:18 <NobodyCam> but you have read the data blob to see whats being requested #1
19:50:29 <NobodyCam> s#1/with #1/
19:50:45 <devananda> what i like about #2 is that the driver's method is required by the URI, not by the message body
19:50:57 <lucasagomes> yea it's looks more clear indeed
19:51:07 <NobodyCam> much better said then my words
19:51:23 <NobodyCam> 10 minutes left
19:51:33 <lucasagomes> ok so... we are inclined to use the #2 model
19:51:41 <lucasagomes> I will reasearch it, see if I can find some examples
19:51:44 <NobodyCam> +1 from /me
19:51:44 <lucasagomes> and do a prototype
19:51:53 <NobodyCam> awesome TY lucasagomes :)
19:51:57 <devananda> also, it lends itself much better to the approach of "we dont introspect the body for vendor_passhthru"
19:52:05 <NobodyCam> linggao: you still here
19:52:10 <NobodyCam> ?
19:52:15 <devananda> the goal really being that ironic just blindly passes what ever data it gets to the driver
19:52:19 <linggao> yes, I am here
19:52:34 <devananda> lucasagomes: so the routing (ie, the driver.method) being in the URI, not the body, is really best, IMO, if we can do that
19:52:53 <NobodyCam> :) linggao do you have anyquestions we can help with?
19:52:57 <lucasagomes> will try that when I get a time to a prototype
19:53:05 <devananda> ty
19:53:16 <lucasagomes> I'm still working on some internal things and upstream half-time each
19:53:21 <lucasagomes> but I will try to do it this week
19:53:27 <NobodyCam> :)
19:54:05 <NobodyCam> linggao: was looking at doing power on / off
19:54:29 <linggao> NobodyCam, I will ask after meeting. It's more like how to setup the client-server connection for ironic conductor
19:54:34 <NobodyCam> was just seeing if you got an answer to your questions in channel
19:54:50 <lucasagomes> NobodyCam, power on power off? virtualdriver (sshdriver)?
19:55:17 <linggao> I got some idears from danvananda and you and lucas, trying them now.
19:55:31 <lucasagomes> :) ok
19:55:34 <NobodyCam> w00t,
19:55:59 <NobodyCam> lucasagomes: more the frame work for start_power_state_change
19:56:23 <linggao> lucasagomes: I am trying to see if I can help on the function in conductor manager.
19:56:28 <devananda> one quick announcement, just in case anyone hasn't heard
19:56:35 * NobodyCam still unsure about start_ prefix
19:56:37 <lucasagomes> linggao, ahh sweet!
19:56:50 <NobodyCam> lol
19:57:02 <devananda> I'll be GONE for the next 2 weeks. No email, no phone, etc... so. NobodyCam will be running the show :)
19:57:09 <NobodyCam> ieek
19:57:19 <linggao> lucasagomes: have to make sure to get connected from your client side.
19:57:26 <lucasagomes> NobodyCam, hehe I couldn't think about anything better as well, I just renamed form start_state_change to start_power_state_change since we now have power and provision states
19:57:38 <NobodyCam> ya
19:57:42 <NobodyCam> :-p
19:57:52 <NobodyCam> I'm in the same boat I think
19:57:55 <NobodyCam> lol :)
19:58:00 <devananda> lucasagomes: ++. provisioning will be a challenge to do driver-independently
19:58:11 <lucasagomes> yea
19:58:30 <lucasagomes> devananda, a note to ur note... enjoy the burning man :)
19:58:39 <lucasagomes> saw some videos, looks awesome
19:58:44 <devananda> lucasagomes: thanks!
19:58:50 <NobodyCam> Awesome meeting everyone!
19:59:10 <NobodyCam> devananda: Enjoy the brun... We will be thinking abut you
19:59:16 <devananda> thanks, everyone! ya'll are doing awesome things ~~ I look forward to seeing all the great changes when I get back :)
19:59:30 <linggao> devananda: enjoy the vacation.
19:59:38 <NobodyCam> any last words?
19:59:58 <NobodyCam> and with that:
20:00:01 <NobodyCam> #endmeeting