19:00:52 <devananda> #startmeeting ironic
19:00:53 <openstack> Meeting started Mon Jul 22 19:00:52 2013 UTC.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:57 <openstack> The meeting name has been set to 'ironic'
19:01:21 <devananda> hi!
19:01:34 <devananda> looks like we have a pretty full agenda today, which is great to see
19:01:37 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:02:21 <devananda> lucasagomes: know if martyn is going to join us today?
19:02:25 <NobodyCam> wow we do
19:02:41 <devananda> there are a lot of API things on the agenda, and i think his input would be useful
19:02:43 <lucasagomes> devananda, I don't know, lemme see if he's around
19:02:47 <devananda> thanks
19:04:07 <lucasagomes> not really, he's not on the RedHat channels as well
19:04:18 <devananda> hm, k
19:04:26 <devananda> well, let's get started then
19:04:36 <devananda> #topic to XML or not to XML
19:05:00 <devananda> is there a compelling reason for XML support initially?
19:05:04 <NobodyCam> why use xml?
19:05:21 <lucasagomes> right, so should we support XML? as far as i know WSME works "OK" with xml responses
19:05:34 <lucasagomes> if I could vote I'd say -1 to xml
19:05:49 <NobodyCam> my initial thoughts are we don't need it
19:05:54 <NobodyCam> lucasagomes: :)
19:05:54 <romcheg> As I know some guys use XML in production.
19:06:06 <lucasagomes> martyntaylor, hey!
19:06:11 <devananda> i don't know enough about client lib requirements to be sure, but i am keen on keeping things simple initially
19:06:28 <NobodyCam> romcheg: json is also very standard
19:06:35 <martyntaylor> lucasagomes: yo, sorry was a little late
19:06:51 <devananda> so if we don't absolutely need xml in rev1, let's put it on the back burner. we will probably want to support it eventually
19:06:59 <devananda> martyntaylor: hi! glad you could make it :)
19:07:05 <NobodyCam> devananda: +1
19:07:07 <romcheg> I agree with devananda
19:07:10 <lucasagomes> devananda, +1
19:07:13 <anteaya> o/
19:07:35 <martyntaylor> devananda: +1 since the API is still evolving we may as well invest the effort in XML once its more stable
19:07:43 <devananda> great
19:08:02 <devananda> #agreed no XML support in rev1, to streamline our work on the JSON API
19:08:16 <devananda> #topic PATCH request format
19:08:28 <devananda> lucasagomes had found some good info on this last week... still have the links?
19:08:44 <lucasagomes> http://docs.openstack.org/api/openstack-image-service/2.0/content/update-an-image.html
19:08:49 <lucasagomes> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10
19:09:26 <lucasagomes> so, first, we need to agree with a patch format
19:09:31 <lucasagomes> and put it in our spec api
19:10:25 <martyntaylor> lucasagomes: I'd note for using the json patch format for 2 reasons.
19:10:36 <devananda> #link http://docs.openstack.org/api/openstack-image-service/2.0/content/update-an-image.html
19:10:39 <martyntaylor> 1. it's used else where in openstack, i.e. the example you just gabe
19:10:41 <devananda> #link http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10
19:10:52 <devananda> (add #link sticks it in the .html meeting summary)
19:10:57 <martyntaylor> 2. it's the closest thing to a standardised format
19:11:12 <martyntaylor> the negative, is that it's trickier to implement
19:11:29 <martyntaylor> once quesiton I have though, is that do we need PATCH in rev1
19:11:32 <lucasagomes> martyntaylor, I think there's a python lib which implents that already
19:11:44 <lucasagomes> https://github.com/stefankoegl/python-json-patch
19:12:08 <lucasagomes> https://pypi.python.org/pypi/jsonpatch/0.6
19:12:19 <devananda> consumers of the ironic API will frequently be changing one or two parameters at a time
19:12:30 <devananda> so PUT, even for sub resources, is less than ideal
19:13:20 <martyntaylor> devananda: yeah, I can certainly see its value.  But it is just another (albeit more efficient way) to update a resource and we already support PUT
19:13:29 <NobodyCam> so patch instead of delete / readd
19:13:30 <devananda> so either we require all API clients to GET then PUT a complete (sub)resource, or we allow PATCH.
19:13:59 <martyntaylor> I wonder whether effort is better spent implementing one update method and getting a v1 release of the API, then add in PUT or PATCH in necxt rev
19:14:23 <NobodyCam> martyntaylor: thats my question too
19:14:26 <devananda> martyntaylor: what would that "one update method" be?
19:14:41 <martyntaylor> PUT and PATCH are both ways to update a resource
19:14:45 <devananda> yes
19:14:50 <martyntaylor> oh
19:14:51 <martyntaylor> sorry
19:15:31 <martyntaylor> yeah so personally I would vote for PUT, since it is part of the HTTP spec
19:15:41 <martyntaylor> but I've no real object to PATCH
19:15:44 <martyntaylor> objection*
19:16:17 <anteaya> the use of PATCH will require education of new contributors, would it not?
19:16:29 <devananda> so here's a problem with not having PATCH
19:16:42 <lucasagomes> problem with put is that it's more a "replace" than an "update"
19:16:55 <NobodyCam> my question is the how much would it delay rev1 release to work in patch
19:17:01 <devananda> when an API client wants to change one attribute of driver_info, it will need to PUT the entire driver_info, including the password. every. single. time.
19:17:21 <romcheg> Why not use UPDATE which is the part of standard HTTP spec?
19:17:49 <devananda> romcheg: aiui, that is PATCH. am I missing some part of the spec?
19:17:50 <romcheg> and also UPDATE is for "updating" not for replacing
19:18:37 <martyntaylor> devananda: yeah that is less than ideal.
19:18:55 <martyntaylor> romcheg: I'm not aware of UPDATE
19:19:07 <romcheg> Hmm
19:19:12 * NobodyCam takes a step back.. I don't think the question is will we support patch/update its do we need it for rev1
19:19:28 <NobodyCam> devananda: ^^?
19:19:44 <martyntaylor> NobodyCam: I think devananda question is if we are to support a single method of update, should it be PATCH or PUT
19:20:02 <romcheg> Looks like I was wrong all these years...
19:20:07 <devananda> romcheg: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9
19:20:23 <romcheg> devananda: yup, already found that
19:20:44 <devananda> PATCH isn't in the 1.1 spec either. it's a somewhat recent extension AIUI, but it's widely used now
19:20:54 <martyntaylor> yeah it's still an RFE
19:20:57 <martyntaylor> http://tools.ietf.org/html/rfc5789
19:21:30 <devananda> so, NobodyCam put it well -- can rev1 function with only one method (put OR patch)?
19:21:35 <devananda> i think we can't function without patch
19:21:46 <martyntaylor> I agree
19:21:52 <devananda> because the requirement that all clients know all data all the time just to update any field is, well, not a reasonable requirement IMHO
19:22:06 <devananda> we need to allow updating single fields
19:22:07 <martyntaylor> oh
19:22:19 <martyntaylor> I read that as we can*
19:22:24 <devananda> :)
19:22:28 <lucasagomes> we also have a problem with the pecan/wsme object representation, the way we were doing PUT was to get the delta object, remove all the NULL fields (creating a delta object) and updating the documents with the fields that was filled
19:22:43 <lucasagomes> now it doesn't allow us set a field to NULL
19:22:52 <lucasagomes> the max you can do is to empty that field
19:23:01 <devananda> lucasagomes: yes. this is part of the reason i haven't landed that patch of mine. i have not been happy with a few implementation / implications of it
19:23:04 <devananda> like that
19:23:28 <devananda> but that was a side effect of using PUT-like semantics, but hacked up to do updates instead of replace
19:24:03 <lucasagomes> devananda, yup, and supporting PATCH would fix that too
19:24:29 <devananda> for structured objects (eg, node, port, chassis) pecan/wsme will provide us with NULL fields for any values not POST/PUT'ed
19:24:47 <martyntaylor> devananda: lucasagomes well we can catch that at the transformation layer
19:24:52 <devananda> for the nested dicts (eg, driver_info, properties, extra) we just get the passed stuff.
19:25:04 <devananda> so PUT needs to completely replace the existing dict
19:25:39 <devananda> and we need PATCH to allow single-field updates of said dicts
19:26:24 <martyntaylor> we also need to be careful about race conditions with updates too
19:26:27 <devananda> (there's another problem with wsme that I need to bring up later -- response code doesn't work today)
19:26:31 <NobodyCam> is it worth landing the current patch and a blueprint to refactor patch support
19:27:14 <NobodyCam> meeting 1/2 over and we are on topic #2?
19:27:18 <devananda> eek
19:27:21 <devananda> NobodyCam: thanks
19:27:31 <devananda> let's table this and move on.
19:27:46 <devananda> #action continue debate about PATCH support
19:27:47 <lucasagomes> right so... let's move on, we can talk about it another time at the #openstack-ironic
19:27:59 <devananda> #topic RPC hooks
19:28:18 <devananda> i think this is a no-brainer and I will land the patch importing Dan's work, unless anyone objects now :)
19:28:29 <NobodyCam> +!
19:28:33 <NobodyCam> 1 even
19:28:38 <romcheg> +1
19:28:54 <lucasagomes> cool :) removed my -1 already
19:28:59 <lucasagomes> so +1
19:29:01 <devananda> great
19:29:12 <devananda> #agreed proceed with importing RPC serliazers
19:29:15 <devananda> #topic testing
19:29:27 <devananda> romcheg: i think you added this :)
19:29:31 <romcheg> Yup
19:29:40 <devananda> and I would be thrilled for ironic to have more/better testing
19:30:05 <romcheg> We have folks here who landed the patch to OSLO that allows to test DB migrations.
19:30:20 <devananda> indeed -- boris-42' teams work has been great there
19:30:29 <romcheg> I have asked yuriz to use it for Ironic
19:30:32 <NobodyCam> we have been in such a state of flux i think its been tuff to ramp up testing
19:30:34 <devananda> ++
19:30:41 <romcheg> We have a BP
19:30:54 <devananda> link?
19:30:55 <romcheg> #link https://blueprints.launchpad.net/ironic/+spec/db-migration-tests
19:31:11 <devananda> #action devananda to review bp: ironic/db-migration-tests
19:31:40 <devananda> as for tempest // devstack integration, I think we're not quite there, but someone could start working on adding ironic to devstack
19:31:51 <boris-42> devanada that was hard)
19:31:52 <romcheg> As I know the patch for Ironic is ready. yuriz told me he will submit it as soon as devananda approves the BP
19:31:53 <devananda> so that by the time we finish the API/RPC work, the devstack bits are in place
19:31:54 <boris-42> devananda ^
19:32:45 <devananda> romcheg, boris-42: do you guys have someone starting on the devstack integration?
19:33:07 <romcheg> No, currently no one's working on that
19:33:15 <devananda> we also have NobodyCam working on diskimage-builder integration, though that won't lead to CI for a while (there are other issues blocking diskimage-builder CI right now)
19:33:32 <devananda> romcheg: k. feel free to toss up a BP. we'll need it eventually :)
19:33:58 <devananda> #action romcheg to post BP for devstack / tempest integration with ironic
19:34:26 <devananda> moving on ... i'm going to skip the next few API items (which we sort of already talked about anyway). I'll come back to them if there's time
19:34:33 <devananda> #topic copyright lines
19:34:42 <devananda> #link https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers
19:34:53 <devananda> everyone should (have) read that (already)
19:35:20 <devananda> any questions?
19:35:36 <jog0> devananda: are you using hacking 0.6 yet?
19:35:54 <devananda> jog0: possibly not. want to post a patch?
19:36:05 <jog0> devananda: it checks for copyright headers
19:36:15 <devananda> cool
19:36:23 <jog0> just makes sure apache2 header is correct and present
19:36:28 <jog0> devananda: sure
19:36:43 <devananda> #action jog0 to update us to use hacking 0.6
19:36:53 <NobodyCam> and check with you employeer
19:37:08 <NobodyCam> s/you/your/
19:37:13 <devananda> ah. yes. some employers have very specific policies for their employees
19:37:22 <martyntaylor> I'm sure there's an eclipse plugin for this hehe :D
19:37:53 <devananda> any other comments on (c)?
19:39:04 <devananda> k, moving on
19:39:09 <devananda> #topic keystone auth
19:39:28 <devananda> i'm good with ironic API being admin-only for now
19:39:46 <devananda> romcheg got that working in a patch. thanks!!
19:39:47 <jog0> devananda: how does that change with v3 keystone API?
19:40:02 <devananda> romcheg: ^ ?
19:40:07 <NobodyCam> but keystone endpoints would be nice
19:40:09 <romcheg> jog0: we use authtoken_middleware
19:40:11 <jog0> see justin santa barbara's ML thread
19:40:34 <jog0> about domains
19:40:40 <romcheg> which allows us to not aware of changes in the keystone api
19:40:51 <jog0> romcheg: how does it sort out domains?
19:41:57 <romcheg> jog0: Oh, I thought you were asking about checking the auth token.
19:43:05 <romcheg> As I know we do not depend on keystone api when we use python-keystoneclient. Not sure about some specific features.
19:43:32 <jog0> romcheg: I am sort of .. disclaimer I don't know alot about v3 keystone API but domains change things I think
19:44:38 <romcheg> Since I have already started working on that part of Ironic, I can make a research on that.
19:44:43 <jog0> ie ca none be an admin of a domain only?
19:44:49 <jog0> can one *
19:44:49 <devananda> perhaps one of you can raise this on the ML, so keystone folks can chime in?
19:45:06 <jog0> devananda: http://lists.openstack.org/pipermail/openstack-dev/2013-July/012292.html
19:45:26 <devananda> my goal is that, at least in ironic rev1, the ironic API be only accessible to a very restricted, privileged set of users
19:45:32 <devananda> eg, "cloud admins"
19:46:55 <NobodyCam> devananda: +1
19:46:56 <romcheg> v3 only appeared in havana, didn't it?
19:46:56 <devananda> #action romcheg to continue discussion about keystone v3 and domains
19:47:02 <NobodyCam> (for now)
19:47:03 <devananda> romcheg: yes. new in havana
19:47:18 <devananda> moving on cause we're short on time
19:47:24 <romcheg> ok
19:47:32 <devananda> #topic PXE driver
19:47:47 <devananda> GheRiver1: hi! any news on the pxe driver or glanceclient patches?
19:49:18 * devananda wonders if GheRiver1 is around ...
19:49:29 <devananda> ok, we'll come back t that if he pops in
19:49:31 <NobodyCam> no news is good news?
19:49:36 <devananda> #topic diskimage-builder
19:49:50 <NobodyCam> i've fallen a tad behind here
19:49:59 <NobodyCam> I should be back on track this week
19:50:30 <NobodyCam> there is a rabbit issue that seems to have popd up .. I need to look in to it more
19:50:55 <NobodyCam> short update is : not quite there yet.
19:52:09 <devananda> k, thanks for the update
19:52:28 <devananda> i skipped a bunch of the API related stuff, but there's one that i need to bring up
19:52:55 <devananda> #topic WSME response object
19:53:21 <devananda> basically, pecan 0.5b2 doesn't fully support the Response object
19:53:59 <devananda> so we can't currently do things like "return 200 or 202, depending on XXX"
19:54:08 <devananda> there's a bunch of #NOTEs in my patch about this
19:54:16 <devananda> and I think it'll affect all of the API work for a little while
19:54:25 <devananda> #topic open discussion
19:54:32 <devananda> 5 minutes left -- go :)
19:54:42 <romcheg> I have a question!
19:54:43 <romcheg> ^)
19:55:26 <romcheg> We have some todos to move the things related to eventlet to ironic.__init__
19:55:26 <lucasagomes> I've another problem with the object representation in pecan/wsme... anyone knows a way to return only a subset of it?
19:56:11 <devananda> lucasagomes: return different subsets from different methods?
19:56:12 <romcheg> I'm not too familiar with pbr. What's our problem with that?
19:56:18 <devananda> lucasagomes: or have different methods return different things
19:56:25 <lucasagomes> devananda, for e.g
19:56:36 <lucasagomes> if we want to support something like this in our api
19:56:42 <romcheg> Currently we import eventlet in ironic.cmd.__init__ and ironic.test.__init-_
19:56:43 <lucasagomes> GET ../chassis/1?fields=uuid,extra
19:56:53 <lucasagomes> it would return only some fields of that chassis
19:57:00 <devananda> lucasagomes: oh. let's not do that :)
19:57:11 <lucasagomes> devananda, yea I know :) it was just an e.g
19:57:14 <martyntaylor> I have a question about transformation in pecan
19:57:21 <martyntaylor> well in particular in wsme
19:57:23 <lucasagomes> but it also works for the list of nodes for example
19:57:32 <lucasagomes> wehere I want to return only the UUID + link
19:57:56 <devananda> lucasagomes: for that, i would create an API class that is UUID + link, and return a list of those
19:57:57 <martyntaylor> would the preferred approach be to use wsme complex types, templates or creating a pecan transformer objects
19:58:07 <devananda> wsme complex types
19:58:11 <devananda> and nested types where necessary
19:58:16 <NobodyCam> lucasagomes: like this  open discussion (Meeting topic: ironic)
19:58:19 <NobodyCam> gah
19:58:20 <martyntaylor> devananda: thanks
19:58:25 <devananda> i spoke (very briefly) with dhellmann last week and that was the conclusion
19:58:30 <NobodyCam> keystone endpoint-get --service ${service_name} | awk 'length($4)!=0 && $4 !="Value" { split($4,x,"/"); split(x[3],y,":"); print y[1] }'
19:58:59 <devananda> romcheg: what's wrong with importing eventlent in .cmd.__init__ and .test.__init__? that seems fairly standard to me?
19:59:09 <lucasagomes> NobodyCam, what you mean?
19:59:12 <NobodyCam> I don't see a big value in parsing the output in our space
19:59:33 <lucasagomes> devananda, gotcha, yea creating another class with both attributes works, will do that then
19:59:34 <NobodyCam> let the user parse the output
20:00:00 <NobodyCam> vs requesting just name and link fields
20:00:01 <romcheg> devananda: it's actually more about gettext than about eventlet.
20:00:09 <devananda> ok, we're out of time. thanks everyone, great meeting!
20:00:14 <martyntaylor> cheers gents
20:00:21 <NobodyCam> o/
20:00:21 <lucasagomes> thanks
20:00:24 <devananda> #endmeeting