19:00:45 <NobodyCam> #startmeeting ironic
19:00:45 <NobodyCam> Welcome to the Ironic Meeting.
19:00:46 <NobodyCam> Who's here today for the meeting?
19:00:46 <openstack> Meeting started Mon Jul  8 19:00:45 2013 UTC.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:49 <openstack> The meeting name has been set to 'ironic'
19:00:58 <GheRivero> o/
19:00:59 <romcheg> Hi
19:01:04 <romcheg> o/
19:01:06 <martyntaylor> howdi
19:01:22 <anteaya> o/
19:01:25 <NobodyCam> welcome GheRivero romcheg martyntaylor anteaya
19:01:45 <NobodyCam> ok so no devananda again this week he should be in a plane right about now. :)
19:01:54 <anteaya> hope he is having fun
19:02:04 <romcheg> having fun… in the plane...
19:02:09 <romcheg> :-P
19:02:16 <NobodyCam> lol I know his boarding was delayed.
19:02:18 <NobodyCam> here's today's agenda
19:02:18 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:02:19 <anteaya> as a result of the plane, perhaps
19:02:52 <NobodyCam> first up:
19:02:52 <NobodyCam> #topic API implementation and refactoring
19:03:00 <NobodyCam> #link https://review.openstack.org/#/c/35990/
19:03:44 <NobodyCam> No JimJiang today
19:03:57 <romcheg> I think authentication is covered by this topic, isn't it?
19:04:09 <NobodyCam> we have a topic just for that
19:04:21 <romcheg> Ah yes, sorry
19:04:27 <NobodyCam> :) hehehe
19:04:33 <epim> yay meetings
19:04:44 <NobodyCam> welcome epim
19:04:52 <martyntaylor> I want to make the observation that we have a considerable amount of code that could be generalised and reused across the API
19:05:00 <NobodyCam> if there are no comments for this one we will move on
19:05:09 <martyntaylor> It maybe best to look at this post v1 of the API implementation
19:05:42 <NobodyCam> martyntaylor: do you have an example of this
19:06:03 <NobodyCam> (* ie what you are thinking about)
19:06:42 <martyntaylor> NobodyCam: not an exact example but with minor tweaks we can for example for create single methods for POST, PUT, DELETE controller actions in a base controller
19:06:52 <martyntaylor> since they are all very similar
19:07:12 <martyntaylor> I have some code on my tree that I wanted to get in that helps with some of this stuff
19:07:27 <NobodyCam> ahh ok. ya I think that may be best handled after we get v1 going
19:07:42 <NobodyCam> we need SOMETHNING then we can make it better
19:07:46 <martyntaylor> NobodyCam: I did run into slight issue with the new RPC model stuff romcheg did you add a comment to the agenda re our discussion this morning
19:07:49 <martyntaylor> NobodyCam: agreed
19:08:21 <romcheg> Ah, just got disconnected
19:08:21 <martyntaylor> romcheg: romcheg did you add a comment to the agenda re our discussion this morning
19:08:47 <martyntaylor> ah this one I guess: Object model: Loading object trees
19:08:49 <romcheg> Yes, I have added a topic after RPC implementation
19:08:53 <martyntaylor> ok I can wait until we get that far
19:08:54 <NobodyCam> :)
19:09:01 <NobodyCam> move on then?
19:09:02 <martyntaylor> NobodyCam: sorry please continue
19:09:10 <NobodyCam> NP :)
19:09:15 <NobodyCam> #topic API checking of keystone auth token
19:09:39 <NobodyCam> ok here we go
19:09:55 <romcheg> Unfortunately I haven't finish with that yet.
19:09:58 <NobodyCam> romcheg: did you have a chance to look at this in out short holiday week
19:10:02 <NobodyCam> :)
19:10:20 <NobodyCam> its tuff when its a holiday
19:10:34 <romcheg> I have a code that is based on pecan hooks
19:10:35 <NobodyCam> good to bump to next meeting
19:11:04 <romcheg> Trying to deal with pecan.deploy instead
19:11:14 <NobodyCam> very cool. do you think you'd be able to put it up for review before next weeks meeting
19:11:24 <romcheg> I think so.
19:11:29 <NobodyCam> :)
19:11:57 <NobodyCam> #action bump keystone auth check to next meeting
19:12:01 <romcheg> Do you think hooks can do the job for us or we need to deal with pecan.deploy to look like other openstack projects?
19:12:42 <NobodyCam> I'm think the peacan.deploy ... if just to stay in sync with other projects
19:12:51 <NobodyCam> *thinking
19:13:37 <NobodyCam> any other comments?
19:13:42 <NobodyCam> or move on?
19:13:45 <romcheg> yup
19:14:00 <NobodyCam> #topic RPC implementation for lock-aware API calls
19:14:10 <NobodyCam> ok we had this:
19:14:11 <NobodyCam> #link https://review.openstack.org/#/c/34115/ (now outdated!)
19:14:34 <NobodyCam> I know its outdated. I'm hoping deva will have a chance to update it
19:14:52 <romcheg> I think devananda wil put his hands on that as soon as he's back
19:15:04 <NobodyCam> any one want to make any comments on this
19:15:09 <NobodyCam> ya I do too
19:15:59 <NobodyCam> ok then moving on. (I love it when meeting go quickly :-p)
19:16:06 <NobodyCam> #topic Object model: Loading object trees
19:16:27 <martyntaylor> ah yes so I think I can try an explain this
19:16:31 <NobodyCam> :)
19:16:48 <romcheg> Yes, that's an interesting problem
19:17:15 <martyntaylor> So, it seems that the object model stuff we inherited from Nova is screwed driectly into the DB API calls
19:17:37 <martyntaylor> i.e. each class implements _from_db_object
19:18:01 <martyntaylor> which takes a result from a db api call and translates it into this nova esc model
19:18:15 <martyntaylor> this is fine when we are dealing with simply objects 1 -> 1
19:18:28 <martyntaylor> but gets more complex when we have object trees
19:18:41 <martyntaylor> like for example a node object with a number of ports, chassis, driver and so on
19:19:48 <martyntaylor> SQLAlchemy would normally handle this sort of stuff, example would be specifying ("join" on the lazy attribute for a relationship would auto load that resource too
19:20:29 <martyntaylor> I guess we are going to need to implement this behaviour ourselves unless anyone else has any ideas on this?
19:20:54 <NobodyCam> can we patch nova to handle the complex objects?
19:21:19 <martyntaylor> I suppose we could implement a default behaviour
19:21:26 <martyntaylor> or implement it for each resource
19:22:48 <romcheg> I think we have to implement this for each db object
19:23:39 <martyntaylor> yes I am thinking that too, though it might be worth investigating how this is handled else where, I wanted to bring up in here in case anyone has experience with this in other projects?
19:23:47 <NobodyCam> lets start by fliing a bug for ironic and see if we can get some more eyes one it
19:23:56 <martyntaylor> sure
19:23:58 <NobodyCam> I also need to look at more closly
19:24:13 <romcheg> We need to check that in nova
19:24:20 <NobodyCam> ya.
19:24:32 <romcheg> I think they might have implemented a solution for that
19:25:28 <martyntaylor> OK so I'll file a bug, and look at nova as the first point of call
19:25:38 <NobodyCam> :) cool!!!!
19:26:19 <NobodyCam> good to move on? or stay on topic
19:26:23 <martyntaylor> sure move on
19:26:24 <martyntaylor> thanks
19:26:42 <NobodyCam> :) will get some eyes (like deva's) on the bug
19:26:45 <NobodyCam> #topic PXE driver and Image utils refactoring
19:26:58 <NobodyCam> Ghe has done some awesome work here
19:27:06 <NobodyCam> #link https://review.openstack.org/#/c/33616/
19:27:06 <NobodyCam> #link https://review.openstack.org/#/c/35272/
19:27:21 <GheRivero> iamge utils is waiting in glanceclient also (just some cosmetical issues) and ready to land
19:27:50 <GheRivero> meanwhile, the same has been ported to ironic, so we can move on in case it takes more time
19:28:12 <GheRivero> related pxe... just some small issues, mostly cosmetical
19:28:24 <NobodyCam> Ghe has bugs to track the removal once it lands
19:29:05 <NobodyCam> this is a bug step for ironic
19:29:29 <NobodyCam> getting close to actually being able to "DO SOMETHING" :)
19:29:29 * anteaya imagine what a bug step looks like
19:29:34 <anteaya> s
19:29:52 <GheRivero> :)
19:30:17 <NobodyCam> any comments for Ghe?
19:30:25 <anteaya> yay Ghe
19:30:28 <anteaya> good work
19:30:36 <NobodyCam> :)
19:30:49 <NobodyCam> again Thank you Ghe
19:31:01 <NobodyCam> moving on then
19:31:05 <NobodyCam> #topic Ironic standup / D.I.B. element status
19:31:09 <NobodyCam> oh this is me
19:31:34 <NobodyCam> I didn't get as much done over the holiday as I would have liked
19:31:50 <anteaya> apparently you enjoyed yourself though
19:31:55 <anteaya> which is good
19:32:04 <NobodyCam> I started to convert manager to conductor this morning
19:32:57 <NobodyCam> I told lucasagomes this morning I would try and have something up for him to look at today
19:33:13 <NobodyCam> so I gota get off my rear
19:33:28 <NobodyCam> any comments / questions for me?
19:34:05 <NobodyCam> ok then now we can move on to the fun stuff
19:34:08 <NobodyCam> #topic open discussion
19:34:46 <NobodyCam> and heres the mission statement preview. NOTE THIS JUST A PREVIEW. We welcome all input on it.
19:34:55 <NobodyCam> #link http://paste.openstack.org/show/6QnkRmwYXg49Qxa1x5dD/
19:36:43 <NobodyCam> any comments / questions on the mission statement?
19:36:49 <anteaya> any background on this?
19:37:04 <anteaya> so far who has been involved in the creation of this preview?
19:37:09 <NobodyCam> well
19:37:27 <NobodyCam> this is an initial draft from deva
19:37:32 <NobodyCam> I got it this morning
19:37:33 <anteaya> great
19:37:36 <anteaya> okay
19:38:07 <anteaya> now what is the larger context for this mission statement (I kind of know, but let's get it in the logs)?
19:38:17 <NobodyCam> last week in the TCL meeting they voted to make programs vs. projects
19:38:37 <NobodyCam> as a result of that Ironic will become a progaram
19:38:53 <NobodyCam> and we will need a mission statement
19:39:09 <NobodyCam> the above is the first draft of this
19:39:48 <anteaya> "Ironic will become a program subject to approval by the TC after the incubation period", yes?
19:41:15 <anteaya> hey jbjohnso we are just looking at this first draft of the ironic mission statement: http://paste.openstack.org/show/6QnkRmwYXg49Qxa1x5dD/
19:41:16 <NobodyCam> no we will automatically be come a progeram (as I under stand it)
19:41:24 <NobodyCam> we are already core
19:41:38 <anteaya> okay, I differ in understanding but that is a conversation for another time
19:41:49 <anteaya> back to the mission statement draft
19:42:07 <JimJiang> What's the difference of programs and projects of htat meeting?
19:42:26 <anteaya> projects are repositories
19:42:39 <anteaya> programs can have many repositories
19:42:55 <anteaya> so a program can have many projects
19:43:11 <JimJiang> I see
19:43:13 <anteaya> for instance openstack-infrastructure is a program that has many projects
19:43:19 <jbjohnso> hmm, on the 'use only open/standard 'tools', does that include open implementation of proprietary non-standard stuff?
19:43:21 <anteaya> so the TC approves of the program
19:43:36 <anteaya> and the program can create the repositories it needs to fulfill its mission
19:43:50 <NobodyCam> jbjohnso: here is the notes from the TC meeting http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-07-02-20.01.log.html
19:43:58 <anteaya> this is a new move since previous to this we only had projects and everything was a project
19:44:41 <NobodyCam> we have one more topic to get through
19:45:04 <jbjohnso> e.g. I was considering that the python-ipmi library would have a scheme for vendors to extend certain generic concepts with proprietary backing
19:45:14 <jbjohnso> e.g. 'sensor' data to include LED state
19:45:37 <anteaya> jbjohnso: that sounds like it would fit the core, standard, vendor divisions of ironic
19:45:55 <NobodyCam> ya
19:45:55 <anteaya> with vendor being a division allowing vendors to do as they choose
19:46:19 <NobodyCam> jbjohnso: kinda like the vendor passthru in iRonic
19:46:30 <NobodyCam> ?
19:46:47 <jbjohnso> anteaya, right, so if python-ipmi has the sensor dict or object have members that are populated according to OEM backends...
19:47:01 <anteaya> I am light on details
19:47:12 <anteaya> but I think that written the correct way, it is possible
19:47:13 <jbjohnso> NobodyCam, to use xCAT as an example 'rvitals' shows all the normal stuff (temp/fans/etc) on any bmc
19:47:37 <jbjohnso> NobodyCam, but it also looks at the manufacturer and jumps to manufacturer defined schemes for more 'vitals'
19:47:47 <NobodyCam> ahh ok
19:48:01 <jbjohnso> northbound of the library, they are just more key,type,value tuples
19:48:04 <jbjohnso> (essentially)
19:48:17 <NobodyCam> let me get this last topic on the plate
19:48:34 <NobodyCam> jbjohnso: /me need to look more closly at xcat
19:48:44 <jbjohnso> NobodyCam, it's in perl...
19:49:07 <NobodyCam> last up.. file injection in images. (http://lists.openstack.org/pipermail/openstack-dev/2013-May/008728.html)
19:49:14 <NobodyCam> Ghe?
19:49:33 <GheRivero> one of the options actually missing in ironic is fileinjection
19:49:56 <GheRivero> the discussion mainly raises security and scalability concerns
19:50:12 <GheRivero> but no consensuss was reached
19:50:26 <jbjohnso> AFter much contemplation on that, my vote is that any 'special' stuff should be scoped to a single credential exchange
19:50:37 <NobodyCam> GheRivero: am I correct in my understanding that we currently NEED file injection?
19:50:44 <jbjohnso> and then some secure network protocl scheme be used for a while
19:50:48 <jbjohnso> for the rest
19:51:02 <jbjohnso> I don't know what I'm talking about, but I heard the word metadata service crop up
19:51:04 <GheRivero> NobodyCam: uhmm. i think everything can be done with cloud-init
19:51:25 <NobodyCam> jbjohnso: hows that secure cred exchange lib comming along?
19:51:43 <jbjohnso> NobodyCam, well, I can offer options, but didn't know if there was a consensus
19:51:56 <jbjohnso> NobodyCam, e.g. you could say 'all PXE booted nodes shallbe chained to ipxe'
19:51:58 <NobodyCam> GheRivero: how about inital network config
19:52:15 <jbjohnso> NobodyCam, and then embed site creds in that payload to auth https downloads
19:52:18 <GheRivero> that0s the one i am looking now
19:52:20 <jbjohnso> NobodyCam, and static net config
19:52:51 <jbjohnso> NobodyCam, then you could close the security loop by using a remote media ipl strategy
19:53:08 <jbjohnso> and the insecure path could remain, and converge early with the secure path
19:53:08 <NobodyCam> there was an effort to remove FI from nova baremetal
19:53:24 <jbjohnso> now the question is on the flip side
19:53:27 <NobodyCam> and I believe its still there
19:54:10 <GheRivero> yeah...all people want to get rid of it, once a fully replacement is done... but i don't know the missing pieces
19:54:12 <jbjohnso> the flip side I can think of three paths
19:54:17 <NobodyCam> fyi we have 5 minutes left inthe room
19:54:34 <jbjohnso> network link local (limits network switch choice, fragile in the face of... exotic network configs)
19:54:56 <jbjohnso> serial (standard, my favorite, some people look at you weird for saying serial)
19:55:09 <NobodyCam> GheRivero: can I add a action item for you to look in to the FI stuff
19:55:15 <jbjohnso> and bmc storage (proprietary, differs vendor to vendor, limits compute vendor selection)
19:55:26 <NobodyCam> jbjohnso: serial over lan?
19:55:27 <GheRivero> sure
19:55:31 <jbjohnso> NobodyCam, yeah
19:55:48 <jbjohnso> NobodyCam, *iff* you manage IPMI correctly (big assertion), then it's nice and *mutually* authenticated
19:55:58 <NobodyCam> #action Ghe to look into file injection issues in ironic. (ie do we need it)
19:56:03 <jbjohnso> conceptually, you are extending chain of trust based on ipmi device
19:56:39 <jbjohnso> you have to extend trust from something else without any existing state
19:56:51 <NobodyCam> jbjohnso: not today but maybe tomorrow lets talk about hte serial thing
19:56:54 <jbjohnso> the ethernet switch and the service processor are the only two candidates..
19:56:55 <jbjohnso> ok
19:57:06 <NobodyCam> I like that
19:57:15 <NobodyCam> nice a univeral
19:57:21 <NobodyCam> s/a/and/
19:57:47 <NobodyCam> * Universal
19:57:52 <jbjohnso> I actually did the switch one already in another project (not public), but without SNMP and LLDP-MIB.... it's less interesting.  It also limits keysize to something that can fit in 255 bytes base64...
19:58:26 <jbjohnso> but that key is valid for a few seconds, so it's no big deal...
19:58:37 <jbjohnso> but the snmp/lldp stuff is a bigger deal
19:58:39 <NobodyCam> humm
19:59:07 <jbjohnso> since pci passthrough *and* cheap switches impact it
19:59:18 <anteaya> time to wrap up, methinks
19:59:23 <NobodyCam> yep
19:59:34 <anteaya> great meeting NobodyCam
19:59:40 <NobodyCam> wanted to THANK YOU ALL FOR THE GREAT WORK
19:59:40 <anteaya> back to the room
19:59:53 <NobodyCam> #endmeeting