19:01:37 <devananda> #startmeeting ironic
19:01:38 <openstack> Meeting started Mon Jun 17 19:01:37 2013 UTC.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:42 <openstack> The meeting name has been set to 'ironic'
19:01:55 <GheRivero> hi all
19:02:13 <devananda> looks like not much has changed on the agenda, but we have a few things to talk about
19:02:25 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:02:30 <epim> wooo, meetingtime!
19:02:41 <devananda> #topic object model
19:03:04 <devananda> so
19:03:11 <devananda> romcheg and i have been working on the object model
19:03:23 <devananda> i think it's done enough at this point,
19:03:30 <devananda> though one more part is still in review
19:03:57 <devananda> nested dicts -- https://review.openstack.org/#/c/33082/3/ironic/objects/utils.py
19:04:25 <devananda> i was hoping romcheg would be here to talk about objects, but he's not
19:04:34 <romcheg> hmm
19:04:39 <romcheg> I'm going to call him :)
19:04:39 <devananda> oh! there he is
19:04:42 <devananda> :P
19:05:03 <devananda> so, anything to say about object, db models, etc?
19:05:18 <romcheg> I fonutd a strange thing
19:05:23 <NobodyCam> we had questions this morning about a db api spec
19:06:08 <romcheg> Some models are not defined in ironid.db.models but are defined in ironic.db.sqlalchemy.models
19:06:50 <devananda> yes. ironic.db.models is old and i'm deleting it in review 33082
19:07:33 <romcheg> Ah, exactly
19:07:46 <anteaya> o/
19:07:55 <devananda> i'm also removing ironic.api.model
19:07:56 <romcheg> I'm also working on chassis
19:08:17 <romcheg> Yeah, I remember reviewing this one
19:08:32 <devananda> i think we'll end up with 3 classes describing things
19:08:43 <devananda> db.sqlalchemy.models
19:08:53 <devananda> db.sqlalchemy.models.Thing
19:08:57 <devananda> objects.thing.Thing
19:09:02 <romcheg> We might also need MetaData objects
19:09:17 <devananda> api.controllers.v1.Thing
19:10:14 <devananda> romcheg: metadata objects for what?
19:10:56 <romcheg> As I recall, we need MetaData for everything. Shouldn't that be a common thing for nodes, ports, etc?
19:11:26 <devananda> ah, right
19:11:39 <devananda> so at the moment, i dont know what will be stored in that metadata field
19:11:52 <romcheg> Me neither :)
19:12:08 <romcheg> So yes, I think we can leave without that now
19:12:10 <devananda> i suspect we probably shouldnt strongly type it, and allow the user to use it as needed, at least initially
19:12:21 <devananda> node already supports this with the 'extra' field
19:12:58 <devananda> the patch I have up allows any JSON to be supplied for driver_info, properties, and extra -- it converts to dict for use in the code, and back to JSON for storage in the db
19:13:20 <devananda> how does that sound? suficient for our present needs?
19:13:44 <romcheg> extras are stored in the same table, metadata can be stored separately
19:13:53 <devananda> ahhh
19:14:15 <devananda> nova's separate key/value metadata tables are a performance nightmare :)
19:14:38 <romcheg> Then we can get rid of them?
19:15:25 <devananda> i think we can get the same functionality with a JSON field that nova gets with a k/v table.
19:15:59 <devananda> (i'm not about to try removing it from Nova, though :) )
19:16:10 <romcheg> It might be quite hard to search through the extra infos like these
19:16:31 <devananda> sure, but do we need to search through them?
19:17:13 <romcheg> If the information exists we might need to search through it :)
19:18:24 <devananda> hm, so i can see one possible need to search it today
19:18:45 <romcheg> I think for now it's not so important
19:18:50 <devananda> "find node with property X == value Y", eg "find node with 16 GB RAM"
19:18:51 <devananda> however
19:19:14 <devananda> this is done at the scheduler in Nova, so it will not be implemented as a query in Ironic
19:19:28 <devananda> ironic will export the whole 'properties' metadata field to nova scheduler
19:20:05 <devananda> i think for now this is simpler, and we can split it out later if necessary
19:21:00 <romcheg> Agree
19:21:05 <devananda> ok, going to move on so we dont run out of time :)
19:21:12 <devananda> #topic API implementation
19:21:31 <devananda> i think martyn hasn't done much on this as he was waiting on the objects
19:21:41 <devananda> but i put up a review which shows how to use objects in the API
19:22:09 <devananda> i think we're ready to start splitting that up and implementing it in parallel, particularly once chassis object is also done :)
19:22:43 <devananda> as neither martyn nor jayg are here, i'll wait a minute in case anyone else wants to comment, and then move on
19:22:56 <romcheg> I'm going to put chassis to review tomorrow
19:23:07 <NobodyCam> w00t
19:23:10 <devananda> great!
19:23:33 <devananda> #topic image utils and pxe driver
19:23:43 <devananda> GheRivero: hi! how's that going?
19:24:19 <NobodyCam> welcome cody
19:24:26 <GheRivero> iamge tools alsmost done. only some tests and docstrings missing.
19:24:40 <devananda> awesome!
19:24:53 <GheRivero> i have to redo part of it to content glanceclient devs and use versioned clients
19:25:02 <GheRivero> https://review.openstack.org/#/c/33327/
19:25:21 <GheRivero> but confident to be ready early this week
19:25:51 <devananda> k
19:26:06 <GheRivero> and about pxe, i will update it to this review meanwhile
19:26:28 <devananda> let's try to split the pxe rewrite into some manageable parts
19:27:12 <NobodyCam> I'll gladly pickup some pxe bits
19:27:17 <GheRivero> yeah, sure
19:27:34 <devananda> putting up a review with pxe.py based on the new image utils is probably first step
19:27:59 <devananda> another with it using the new TaskManager/ResourceManager, and maybe the new object models
19:28:17 <devananda> i'm not sure how well these three changes can be parallelized though ... :)
19:28:22 <devananda> ideas welcome, too :)
19:29:08 <GheRivero> i will prepare a review with the image tooll tonight, and we can start working from there
19:29:41 <devananda> k. i'll be only half around tomorrow, but will try to at least comment on reviews. should be able to do more the rest of the week
19:30:07 <devananda> anything else on the pxe driver that folks want to talk about?
19:31:10 <devananda> ok, moving on
19:31:13 <devananda> #topic open discussion
19:31:33 <NobodyCam> great job so far everyone!
19:31:44 <anteaya> our reviewers are reviewing more: http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt
19:31:50 <anteaya> thanks to everyone for reviewing
19:31:52 <NobodyCam> happy to see anteaya's first review :)
19:31:59 <devananda> \o/ go reviewers!
19:32:06 <anteaya> you mean my patch you could review?
19:32:18 <anteaya> you missed my first teeny bug fix patch
19:32:19 <NobodyCam> hehehe oh ya that one ....
19:32:50 <devananda> ah, so that reminds me if folks want to contribute but aren't sure yet what code to write
19:32:58 <devananda> we are lacking unit tests for lots of things :)
19:33:03 <GheRivero> any news on the meeting?
19:33:17 <NobodyCam> that there are lots of todo's through the code
19:33:50 <devananda> GheRivero: thanks for the reminder. I think we probably won't have the meeting at the end of this month, not enough people could commit to make the travel worthwhile
19:34:18 <NobodyCam> oh just fyi ... I will not around friday
19:34:18 <anteaya> devananda: would it make sense to discuss one with at least 2 months notice so romcheg can get a visa if need be?
19:34:27 <anteaya> NobodyCam: okay, thanks
19:34:31 <devananda> anteaya: that would make far more sense :)
19:34:31 <anteaya> I would wonder
19:34:47 <anteaya> devananda: great, now or another time?
19:35:15 <devananda> we could also plan for virtual meetings (hangout, skype, etc)
19:35:33 <romcheg> I applied for a visa
19:35:56 <romcheg> However, it doesn't look like my application will be approved :(
19:36:02 <anteaya> romcheg: :(
19:36:03 <NobodyCam> how long before you hear back romcheg
19:36:18 <romcheg> NobodyCam: NobodyKnows
19:36:26 <NobodyCam> lol
19:36:29 <devananda> anteaya: i dont have any specific ideas around dates or location at this point...
19:36:42 <anteaya> okay
19:36:51 <NobodyCam> how about hongong
19:36:54 <devananda> i'm pretty sure there will be some sessions at hong kong summit
19:36:57 <NobodyCam> hongkong
19:37:12 <devananda> AIUI, as a project, we'll have a separate track
19:37:18 <NobodyCam> we could all have dinner and call it a meeting
19:37:32 <devananda> probably half a day with a room to ourselves or so
19:37:41 * devananda waves hands nebulously
19:37:45 <anteaya> NobodyCam: you clever man
19:38:02 <NobodyCam> lol
19:38:33 <anteaya> I don't think romcheg will need a visa for Hong Kong, will you romcheg?
19:39:10 <romcheg> When is the summit?
19:39:27 <dkehn> November
19:39:30 <romcheg> It's easier to get a visa to Hong Kong
19:39:40 <romcheg> I will ask about funding
19:39:43 <NobodyCam> nov 5 thru the 8th i think
19:39:43 <devananda> #link http://www.openstack.org/summit/openstack-summit-hong-kong-2013/
19:39:52 <romcheg> devananda: thanks
19:40:27 <anteaya> I just got my email for registration today
19:40:46 <romcheg> Ukraine is a post-soviet country. It's not hard to get to Hong Kong, but hard to get to the US
19:40:58 <dkehn> anteaya, yeah 20 mins ago
19:41:08 <anteaya> dkehn: cool
19:41:17 <devananda> indeed, 20 min ago i got one as well
19:41:32 <anteaya> romcheg: good, so makes more sense to plan to see you in Hong Kong then
19:41:55 <devananda> so the question is, is there budget for enough people to have a meeting between now and then to make it worthwhile?
19:42:23 <anteaya> *shrug* from me, I don't know
19:42:35 <devananda> so far, the responses i've gotten have been a lot of maybes, which suggests it's really a "no"
19:42:49 <anteaya> considering the expense of Hong Kong for most
19:43:00 <devananda> indeed
19:43:01 <GheRivero> most people is thinking on HK
19:43:10 <anteaya> might it be better to encourage them to lobby management now so they are in HK
19:43:31 <anteaya> since HK for the design summit is the priority, I feel
19:43:47 <devananda> that seems reasonable to me
19:44:24 <anteaya> okay so romcheg aim for HK
19:44:42 <jbjohnso> I'm preparing to release a native python ipmi library, would folks prefer that to be standalone at PyPI with only glue in openstack
19:44:50 <jbjohnso> or to have the whole thing in openstack
19:44:53 <anteaya> your visa application should be in good shape for that event then
19:45:08 <romcheg> anteaya: Yes, will try to get there
19:45:13 <anteaya> romcheg: great
19:45:14 <anteaya> :D
19:45:33 <anteaya> jbjohnso: good question
19:45:49 <anteaya> mordred: any opinions on the pypi option?
19:45:54 <anteaya> or jeblair?
19:46:20 <jbjohnso> the api as-is, has object constructed: ipmi_command(bmc=bmc,userid=userid,password=password)
19:46:33 <jbjohnso> and then can call functions as such:
19:46:42 <jbjohnso> ipmicmd.get_power()
19:46:49 <jbjohnso> ipmicmd.set_bootdev('network')
19:46:49 <jbjohnso> etc
19:47:04 <jbjohnso> there's async api, but I'll just omit that for now
19:47:41 <devananda> jbjohnso: what's the cost of instantiating the ipmi_command class?
19:48:19 <jbjohnso> devananda, how do you want me to account ;)
19:48:39 <devananda> eg, should we plan to create them on-demand for just one action, or keep the instance in memory for a while?
19:48:57 <devananda> jbjohnso: relative cost is fine :)
19:49:02 <jbjohnso> devananda, reusing it saves about 8 packets on the wire
19:49:22 <jbjohnso> so get_power takes one round trip with 2 packets instead of 10 packets in 5 round trips
19:49:37 <devananda> gotcha. so reuse is good
19:49:52 <jbjohnso> devananda, when I add SOL session support
19:50:04 <jbjohnso> devananda, then a single session can multiplex SOL and non-SOL payload
19:50:27 <jbjohnso> devananda, it should be any more expensive to not reuse than ipmitool as-is
19:50:42 <jbjohnso> devananda, ipmitool has to do the same negotiation after all
19:51:00 <devananda> jbjohnso: right. good to know this can be more efficient :)
19:51:30 <devananda> i'm sure we'll dig into that in more detail when we start writing the driver interface for it
19:51:30 <jbjohnso> devananda, one thing though is session keepalive currently isn't handled, so it will crater if idle too long
19:51:58 <devananda> since mordred doesn't seem to be arond, i'll take a few guesses at the in-or-out-of openstack question
19:52:03 <devananda> but he's really the best one to answer
19:52:27 <jbjohnso> the driver is probably going to cross the 1,000 lines of code threshold shortly (easily if I add SOL)
19:53:17 <NobodyCam> jbjohnso: keep on rock'n
19:53:23 <linggao> devananda: I have discussed with jbjohnso on his native ipmi implementation, I personally think that the his APIs should confirm with the ironic.drivers.PowerInterface.
19:53:27 <devananda> it sounds like you've already implemented it as a library
19:53:54 <linggao> and the ironic.conf file can decide to load in ipmi.py or native_ipmi.py
19:54:07 <jbjohnso> devananda, yeah, my sync api example to make a python 'ipmitool' with subset of function is about 20 lines of code
19:54:08 <devananda> so whether you put it "in" openstack (eg, on stackforge) or not is up to you -- whether you want openstack's tooling, testing, etc
19:55:17 <devananda> jbjohnso: i'd encourage you to put the code on stackforge, even if it's a separate library
19:55:35 * NobodyCam notes that is the 5 (five) minute bell
19:55:43 <devananda> so that development still follows the openstack tolling
19:55:45 <devananda> tooling
19:55:57 <devananda> but it's up to you. i dont see why ironic couldn't consume something from pypi
19:56:01 <jbjohnso> 'tolling' eh, now the truth is revealed
19:56:05 <devananda> :p
19:56:38 <devananda> linggao: if it's implemented as a separate python library, i think we can easily have another PowerInterface for native_ipmi that wraps said library
19:56:53 <devananda> linggao: so i dont think it needs to be implemented _as_ a PowerInterface
19:57:03 <devananda> but we will need a separate PowerInterface for it
19:57:31 <linggao> then how does the code decide which PowerInterface to call?
19:57:40 <jbjohnso> basically, the library sucks up kg, userid, password, bmc address in generic fashion
19:57:49 <devananda> linggao: config option just like you suggest
19:58:03 <jbjohnso> and whatever is in the modules directory would be the bit that understands openstack configuration and such
19:58:28 <linggao> if native ipmi and the ipmi.py have the same functions, why do we need antoher PowerInterface?
19:58:51 <devananda> linggao: well, in the long term, we dont :)
19:59:08 <linggao> I thought PowerInterface is an abstact layer for all the implementations to follow.
19:59:11 <devananda> linggao: but at least for now, i dont want to remove a working PowerInterface until the new one is proven
19:59:22 <devananda> ahh
19:59:23 <devananda> yes
19:59:39 <devananda> by "another PowerInterface", I Meant another subclass
19:59:42 <NobodyCam> one minute to go...tic toc...*theam from jepordy playing in background*
19:59:53 <NobodyCam> theme even
19:59:53 <devananda> we're out of time, so let's move any remaining conversation back to -ironic channel
19:59:59 <linggao> right.
19:59:59 <devananda> thanks everyone! see you next week
20:00:03 <devananda> #endmeeting