19:00:38 <devananda> #startmeeting ironic
19:00:39 <openstack> Meeting started Mon Aug  5 19:00:38 2013 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:42 <openstack> The meeting name has been set to 'ironic'
19:00:53 <devananda> welcome :)
19:01:11 <NobodyCam> :)
19:01:33 <devananda> as usual, here's a link to the agenda: https://wiki.openstack.org/wiki/Meetings/Ironic
19:01:43 <devananda> romcheg might not be around for some of the meeting, so i'd like to let him cover his topics first
19:01:55 <devananda> which, iirc, is keystone integration, and possibly devstack?
19:02:14 <romcheg> so
19:02:26 <romcheg> thank you for letting me to be the first reporter
19:03:22 <romcheg> I have spoken to the guy who is fixing the keystone bug. He was about to commit the patch today or tomorrow.
19:03:50 <romcheg> As soon as it it landed to keystone, we can add v3 domains support
19:03:57 <devananda> great!
19:04:16 <romcheg> next: devstack
19:05:02 <romcheg> It works on my environment, but I was not able to make it to get installed on a clean VM yet
19:05:47 <romcheg> I arranged a meeting with some guys familiar with it so tomorrow I will ask questions to them
19:06:21 <romcheg> that's the progress
19:06:24 <devananda> romcheg: i also know a fair bit about devstack (or did a few months ago). happy to help if i can
19:06:36 <NobodyCam> romcheg: do you have a smaple of the error you can pastebin to us
19:06:58 <romcheg> Not now, I'm here from an iPad
19:07:12 <NobodyCam> ahh :)
19:07:27 <romcheg> let's do that tomorrow
19:07:33 <NobodyCam> you got it :)
19:07:43 <romcheg> NobodyCam: thanks
19:07:54 <jdob> romcheg: when that's all up and working, how would I know? is there an ironic mailing list that you'd announce it on?  (new here, sorry if that's a dumb question)
19:08:11 <devananda> jdob: we use the [Ironic] tag on subject lines to the openstack-dev list
19:08:26 <jdob> excellent, thanks
19:08:42 <NobodyCam> thank you romcheg :)
19:08:51 <romcheg> I will post an announce when ironic support is merged to devstack
19:09:32 <romcheg> Thanks again for your attention. I have a few questions for an open discussion so you will see me again today :)
19:09:43 <NobodyCam> :)
19:09:45 <devananda> romcheg: once your devstack code is at a point you can share // others might be able to experiment with it, i'd also like to take a look, even if its just on github :)
19:10:07 <romcheg> devananda: sure
19:10:08 <devananda> romcheg: thanks for the report! enjoy cooking :)
19:10:32 <devananda> ok, back to the scheduled agenda --
19:10:34 <romcheg> thanks
19:10:39 * NobodyCam notes romcheg is bringing the food
19:10:44 <devananda> #topic tripleo / diskimage-builder integration
19:10:52 <devananda> NobodyCam: it sounded like you are really close to this?
19:10:53 <NobodyCam> oh thats me
19:10:57 <NobodyCam> :)
19:11:34 <NobodyCam> I have been using the ironic element to work with deva on the conductor issue
19:11:55 <GheRivero> o/
19:12:40 <NobodyCam> I will be proposing that element to triple-o today (i hope)
19:13:24 <devananda> NobodyCam: cool, thanks!
19:13:25 <NobodyCam> the conf set is very min at this point but does seem to mostly working
19:13:41 <devananda> NobodyCam: have you talked at all with pleia about integration with TOCI?
19:14:02 <NobodyCam> I have not. I will
19:14:16 <devananda> k. it may be too early -- i'm not sure TOCI is functioning yet -- but that should be on both of your radar :)
19:14:49 <NobodyCam> will do.
19:15:00 <devananda> k, moving on
19:15:11 <devananda> #topic glance image utils
19:15:23 <devananda> GheRivero: hi! it looked really close to landing, and then ....
19:15:58 <GheRivero> yeah. some one complaint about glance v2 api support, that wasn-t even in glanceclient, ut solved now
19:16:37 <GheRivero> I know some people is starting to working on features on top of the image service, so holefully that will force reviews to clean the queue
19:16:39 <devananda> for reference -
19:16:41 <devananda> #link https://review.openstack.org/#/c/33327/
19:17:10 <devananda> so it looks like we need to just get a few reviews on that again, yes?
19:17:35 <GheRivero> yeah, but i have contact some revierw in the #openstack-glance channel
19:17:46 <GheRivero> and i will start complaining all the days :)
19:17:46 <devananda> k
19:17:58 <devananda> flaper87: don't suppose you're around?
19:18:07 <devananda> we'd love another review of ^ :)
19:18:54 <devananda> GheRivero: sometimes offers of beer also work ;)
19:19:18 <devananda> any sense of whether this will land in glanceclient in Havana?
19:19:46 <NobodyCam> when in final cut off date?
19:19:51 <GheRivero> i hope so. Anyway, i have a local ironic review updated just in case
19:19:55 <devananda> if not, i'm inclined to land the ironic port of it that you had up, just so we can proceed with testing the PXE driver over the next few months
19:20:12 <jog0> devananda: clients don't have the same release cycle
19:20:44 <devananda> NobodyCam: https://wiki.openstack.org/wiki/Havana_Release_Schedule
19:21:19 <devananda> jog0: right, thanks. but my point is to use this functionality in ironic soon, we either need it in glanceclient, or we take a temporary (and large) patch, then revert it when glanceclient merges & releases
19:21:30 <GheRivero> uhm... too close. i will give it one more week
19:21:31 <devananda> * the equivalent patch
19:21:41 <devananda> GheRivero: ack, thanks
19:22:29 <devananda> GheRivero: any updates on the PXE patch? it seems like it's just blocked on glance still?
19:22:39 <devananda> *glanceclient
19:23:26 <GheRivero> waiting for it. I tested if manually and works, so once the image service is there, should be pretty quickly
19:24:10 <devananda> awesome!
19:24:32 <devananda> thanks for the updates
19:24:42 <devananda> #topic ipmi name conflict
19:24:46 <devananda> linggao: around?
19:25:01 <linggao> hi devananda
19:25:02 <linggao> yes
19:25:06 <NobodyCam> hey linggao :)
19:25:12 <linggao> basically, I am trying to add the native python ipmi driver into ironic. It depends on the native ipmi code that jbjonso wrote (python-ipmi) which is installed on ./.tox/venv/lib/python2.7/site-packages/ipmi/.  So in my driver code native-ipmi.py, I have
19:25:18 <linggao> from ipmi import command as ipmi_command
19:25:24 <linggao> but there is a ipmi.py on the same directory ironic/drivers/modules/. The import failed with "module not found error".  How to resolve this name conflict?
19:26:19 <devananda> renaming ironic/drivers/modules/ipmi.py should be a fairly self-contained patch
19:26:34 <devananda> and seems reasonable to me
19:26:53 <devananda> eg, to ironic/drivers/modules/ipmitool.py
19:27:13 <linggao> do we have larger issue here for name convention?
19:28:09 <devananda> hm
19:28:27 <devananda> conflict is between a module in the same dir vs. a global module
19:28:44 <linggao> yes,
19:29:07 <jdob> IMO, that's a fairly rare occurrence
19:29:16 <linggao> we may encounter the same problem later if we pull in another globle module.
19:29:39 <devananda> it seems fairly rare for global python modules to use short and generic names like "ipmi" or "pxe" or "ssh"
19:30:07 <jdob> i ran into it once having a file named rpm.py and it masking an existing rpm library, but that's the only time I've run into it
19:30:21 <linggao> should jbjonso change the path ipmi to something more unique?
19:30:43 <NobodyCam> linggao: that was my thought to
19:31:16 <jdob> if that's possible, it might be worth it. a name that generic sounds like it comes from python itself
19:31:29 <NobodyCam> I pinged jbjohnso_ in ironic but I don't think he is around
19:31:38 <linggao> so either we make our module/file name more unique, or we require the globle modules be more unique.
19:32:23 * NobodyCam like the idea of changing the rest of the world to fix iRonic
19:32:30 <NobodyCam> *likes
19:32:32 <jdob> :)
19:32:41 <linggao> :)
19:33:09 <NobodyCam> but we may not be able to in other cases
19:33:10 <jdob> maybe i'll submit my patch that contains sys.py afterall  :)
19:34:09 <devananda> i think this is a unique situation since python-ipmi is developed by us
19:34:26 <devananda> so yea, renaming that is definitely possible, and i can see that the name is so short it appears built-in
19:34:58 <devananda> i was trying to brose pypi to see if there are other examples of non-python-native modules with trivially short names
19:35:47 <devananda> so while I think that's probably better for the python-ipmi project itself
19:36:11 <devananda> we may still want to rename ironic/drivers/modules/ipmi.py so that it is clear this one is "ipmitool" and the one linggao is developing is "native-ipmi"
19:36:34 <devananda> i am leaning towards both :)
19:36:34 <linggao> yes.
19:36:41 <NobodyCam> devananda: ++
19:36:54 <devananda> cool. linggao - want to do that rename patch?
19:37:02 <NobodyCam> thats a file name and setup.cfg update?
19:37:06 <linggao> yes. I'll do it.
19:37:07 <jdob> +1 to both
19:37:29 <devananda> NobodyCam: no. file name change, then change several imports. setup.cfg shouldn't have to change as that points to the driver, not the driver.module
19:37:42 <linggao> so ipmi.py will be renamed to ipmi-cmd.py, is that ok?
19:38:05 <linggao> or ipmitool.py?
19:38:16 <devananda> linggao: and then the new one will be ipmi-native.py?
19:38:23 <linggao> tes
19:38:25 <linggao> yes
19:38:26 <NobodyCam> ya
19:38:39 <devananda> let's avoid the '-' in a file name
19:38:55 <devananda> sorry, thinking out loud :)
19:39:08 <NobodyCam> :-p
19:39:30 * NobodyCam votes ipmitool & ipminative
19:39:41 <devananda> yea
19:39:51 <devananda> ++
19:39:56 <linggao> actually new one is native_ipmi.py
19:40:03 <linggao> is _ oky in the name?
19:40:12 <devananda> '_' is ok, yes
19:40:35 <jdob> personally, i'm partial to _ in a name, but i'm also not a dev here :)
19:41:15 <devananda> k, well, let's move on. we can nit pick over names after the meeting :)
19:41:19 <linggao> +
19:41:28 <NobodyCam> :)
19:41:30 <devananda> #actoin linggao to rename drivers/modules/ipmi.py
19:41:39 <devananda> #action jbjohnso to rename python-ipmi module, too
19:41:49 <jdob> devananda: fyi, typo in action on the first one
19:41:58 <devananda> #action linggao to rename drivers/modules/ipmi.py
19:42:01 <devananda> #topic all the API stuff
19:42:19 <devananda> it seems lucas isn't with us today
19:42:30 <devananda> martyntaylor: ah! hi! you're here :)
19:42:39 <NobodyCam> have we covered the conductor issue?
19:42:56 <martyntaylor> devananda: I am indeed :D
19:43:10 <devananda> NobodyCam: ahha! that's not on the agenda, thanks for the reminder.
19:43:45 <devananda> we've been moving a bit slowly today and are running low on time, so let's run through the API and conductor issue (sorry)
19:44:14 <devananda> nested objects looks like it's done
19:44:38 <devananda> i haven't seen any patches for subresources yet, but i imagine lucas will tackle that next
19:45:01 <devananda> no movement that i'm aware of on the WSME error code work (waiting on upstream)
19:45:09 <devananda> and martyntaylor, any thoughts on the PUT v PATCH discussion?
19:45:17 <martyntaylor> devananda: yeah
19:45:33 <martyntaylor> devananda: I've already conveyed these to lucas, so he may have already mentioned it
19:46:09 <martyntaylor> devananda: Given we have limited time, I suggest choosing one method of update
19:46:19 <martyntaylor> (for v1.0 I mean)
19:46:22 <devananda> right
19:46:38 <martyntaylor> if you are going to implement it, then do it right to start
19:46:54 <martyntaylor> so this means implementing PUT properly or PATCH properly
19:46:57 <NobodyCam> patch makes sense to /me
19:47:12 <martyntaylor> both have drawbacks and positive aspects
19:47:17 <devananda> yea. my hackish implementation of PATCH is completely not to spec, and from what lucas found, it's going to be hard to do it to spec with Pecan right now :(
19:47:31 <martyntaylor> but PUT imo seems more standard and easier to implement
19:47:45 <devananda> I beleive we need PATCH, though, based on the way that we plan to do RESTful state changes
19:48:15 <devananda> eg, PATCH /nodes/123 {'power_state': 'ON'}
19:48:21 <martyntaylor> devananda: I'd be suprised if there is stuff that is not acheivable in PUT (though maybe less than optimal)
19:48:58 <devananda> I dont think we can reasonable expect a client to retransmit the entire object -- including the node's IPMI credentials -- for every metadata or state change
19:49:07 <devananda> martyntaylor: so can we do partial changes with PUT?
19:49:25 <martyntaylor> devananda: so
19:49:40 <martyntaylor> devananda: the object model should be sufficiently flexible
19:49:43 <martyntaylor> in this case
19:49:50 <martyntaylor> PUT nodes/123/state
19:50:00 <devananda> aaaah. gotcha
19:50:14 <NobodyCam> ahhh
19:50:17 <devananda> rather than PUT nodes/123 {'state': ...}. I see :)
19:50:30 <NobodyCam> that would work for us
19:50:50 <martyntaylor> yeah I think I have examples in the spec, maybe not for state but for things like driver_info
19:50:54 <devananda> yep. lucas just implemented something similar for nested resources, eg. /nodes/123/ports
19:51:07 <devananda> right. driver_info and parameters are described as sub-resources
19:51:09 <martyntaylor> yeah I had a chat with lucas last week about nested resources
19:51:09 <devananda> nested dicts
19:51:17 <jdob> state isn't exactly a nested resource though (strictly speaking from a REST point of view)
19:51:22 <martyntaylor> or sub resources*
19:51:24 <devananda> jdob: right
19:51:50 <martyntaylor> it's a resource if we say its a resource right
19:52:25 <martyntaylor> it's different to a top level resource in that it only ever lives at /nodes/123/
19:53:03 <devananda> martyntaylor: i think this'll work
19:53:35 <devananda> it's not in the current spec - you or lucas will need to add it so its documented - but just as other properties of a node are exposed as a nested resource currently, i think this is fine
19:53:42 <jdob> what's neat is then you have GET and (for other such attributes where appropriate) DELETE for manipulating them
19:54:04 <jdob> that may be easier than having the body of the PUT be just a delta on the object
19:54:04 <devananda> GET /nodes/123/state is certainly going to be useful
19:54:09 <martyntaylor> devananda: yeah sure, I think it was purposefully left out, because we couldn;t decide on the state model
19:54:18 <martyntaylor> devananda: but happy to add it
19:54:20 <devananda> martyntaylor: indeed, i'm pretty sure you're right :)
19:54:27 <devananda> but it sounds like we have (now)
19:54:30 <martyntaylor> sure
19:54:59 <devananda> ok. we're almost out of time
19:55:04 <devananda> so moving on
19:55:15 <devananda> #topic conductor unable to load drivers
19:55:30 <devananda> like the topic says :(
19:55:38 <devananda> i did a hack to fix it: https://review.openstack.org/#/c/39617/
19:55:46 <devananda> and need to update it with feedback from dhellmann_
19:55:57 <devananda> will do that today :)
19:56:00 <devananda> #topic open discussion
19:56:30 <martyntaylor> devananda: do you guys have a talk submitted to Havana Summit?
19:56:46 <NobodyCam> Thank you all for your votes!
19:56:48 <devananda> martyntaylor: yes. I'll be giving a status update, I believe
19:57:02 <devananda> martyntaylor: lifeless will also be talking about tripleo
19:57:08 <martyntaylor> excellent
19:57:31 <devananda> martyntaylor: and i believe we will have a design track for Ironic. I dont have the details yet, but I'm expecting it to be a half-day or so, as we're still a fairly small project (when compared to nova, glance, etc)
19:57:49 <devananda> martyntaylor: so i'll put out a notice to the list as soon as I have info on that
19:57:56 <martyntaylor> awesome
19:58:00 <martyntaylor> devananda: cheers
19:59:00 <NobodyCam> two minute bell
19:59:34 <jbjohnso_> I came along
19:59:36 <devananda> anyone else have topics / announces ?
19:59:41 <devananda> jbjohnso_: hi there!
19:59:54 <NobodyCam> hey jbjohnso_ we pick in #ironic
20:00:07 <NobodyCam> *we'll pick up in ..
20:00:24 <lifeless> morning
20:00:28 <devananda> k, thanks everyone for joining!
20:00:31 <NobodyCam> morning lifeless :)
20:00:33 <devananda> #endmeeting