19:00:30 <NobodyCam> #startmeeting ironic
19:00:31 <openstack> Meeting started Mon Aug 26 19:00:30 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:34 <openstack> The meeting name has been set to 'ironic'
19:00:43 <NobodyCam> welcome to the ironic meeting
19:00:50 <GheRivero> o/
19:00:50 <romcheg> Greetings folks!
19:00:51 <NobodyCam> who's here
19:00:54 <romcheg> o/
19:01:04 <lucasagomes> :)
19:01:05 <NobodyCam> hey GheRivero romcheg
19:01:10 <yuriyz> good day all
19:01:12 <dkehn> dkehn, :)
19:01:25 <NobodyCam> hey hey look new faces
19:01:40 <NobodyCam> welcome lucasagomes yuriyz an dkehn
19:02:02 <dkehn> I'm always lurking, this is the start of my 3 hours of mettings on monday
19:02:10 <NobodyCam> hehehe
19:02:26 <NobodyCam> ok lets get started
19:02:38 <NobodyCam> #topic testing env
19:02:50 <NobodyCam> firstup devstack
19:03:03 <NobodyCam> #link https://review.openstack.org/#/c/41053/
19:03:12 <NobodyCam> looks like 1 +2
19:03:21 <romcheg> We need another one.
19:03:33 <romcheg> Who is the best person to ping?
19:04:06 <NobodyCam> humm
19:04:25 <romcheg> I have also created a small article #link https://wiki.openstack.org/wiki/Ironic#Try_it_on_Devstack
19:04:31 <anteaya> anyone in -qa
19:04:36 <anteaya> try mtrenish
19:05:01 <romcheg> #action romcheg Ask mtreinish to take a look at Ironic patch
19:05:10 <jdob> romcheg: +1 to that wiki
19:05:24 <NobodyCam> #action romcheg Ask mtreinish to take a look at Ironic patch
19:05:46 <NobodyCam> not sure the action will take if you are not a chair
19:06:00 <romcheg> actions are not for simple mortals :)
19:06:22 <NobodyCam> ok my update with the dib elements.. .is I have no update
19:06:24 <NobodyCam> :(
19:06:36 <NobodyCam> sorry still fighting with my system
19:06:46 <anteaya> :/
19:06:51 <NobodyCam> should be able to get back into it this week
19:06:54 <NobodyCam> (i hope)
19:07:17 <jdob> can you give a quick one line explanation of what you're doing with dib?
19:07:30 <romcheg> NobodyCam: Well, we're not affected by the feature freeze, are we? So nothing bad happens, if there's a small delay
19:08:11 <NobodyCam> we as in ironic no
19:08:27 <NobodyCam> #link https://review.openstack.org/#/c/41480/
19:08:39 <NobodyCam> #link https://review.openstack.org/#/c/41492/
19:09:02 <NobodyCam> those are links for the ironic element I am creating for disk image builder
19:09:10 <jdob> thanks
19:09:41 <NobodyCam> jdob: just fyi I *try* and keep the agenda uptodate
19:09:59 <jdob> oops, sorry, didnt even think to look at that
19:10:05 <NobodyCam> # link https://wiki.openstack.org/wiki/Meetings/Ironic
19:10:20 <NobodyCam> lol its ok I didn't past a link to it
19:10:22 <NobodyCam> :)
19:10:26 <romcheg> I think that should be #agenda
19:10:29 <NobodyCam> paste even
19:10:37 <NobodyCam> +1
19:11:06 <NobodyCam> that it for question / comments on testing env?
19:11:23 <NobodyCam> #topic in-progress tasks
19:11:44 <NobodyCam> Keystone authentication
19:11:56 <romcheg> No good news about that yet
19:12:21 <NobodyCam> romcheg: is there a review I can link in the aganda?
19:12:23 <romcheg> V3 domains still do not work, at least I cannot make them work
19:12:52 <yuriyz> there is keystone bug?
19:12:55 <romcheg> The patch to Ironic is a very small. I cannot upload it until I have at least something that works
19:13:19 <romcheg> yuriz: Yes, I mentioned it in our previous meeting
19:13:28 <romcheg> Cannot find it now so quickly
19:14:10 <NobodyCam> romcheg: if you put a review we can all take a look. I find more eyes is always helpful
19:14:37 <NobodyCam> I'll look for the keystone bug after the meeting and link it into the agenda
19:14:57 <romcheg> NobodyCam: ok
19:14:59 <NobodyCam> romcheg: just mark it as WIP
19:15:01 <NobodyCam> :)
19:15:15 <romcheg> *not after the meeting, in the morning
19:15:26 <NobodyCam> questions / comments on keystone?
19:15:31 <NobodyCam> (hehehehe sure)
19:15:41 <NobodyCam> moving on then.
19:15:47 <NobodyCam> PXE driver
19:15:57 <NobodyCam> GheRivero: wow looking good
19:16:14 <GheRivero> waiting for dib or devstack to start real testing :)
19:16:21 <NobodyCam> #link https://review.openstack.org/#/c/33616/
19:16:35 <yuriyz> good, but corrent
19:16:50 <yuriyz> current code for deploy-helper
19:17:00 <yuriyz> only first step
19:17:02 <romcheg> GheRivero: You can try it on devstack even now
19:17:09 <NobodyCam> #link https://github.com/NoBodyCam/ironic-element
19:17:25 <GheRivero> yeah. that's my plan for this week
19:17:28 <NobodyCam> GheRivero: that will build a ironic image
19:18:34 <NobodyCam> should also have a heat template for starting it
19:19:14 <NobodyCam> any question comments on pxe driver?
19:19:33 <NobodyCam> GheRivero: I will try and review it today
19:19:51 <NobodyCam> moving on then
19:19:59 <NobodyCam> IPMI name conflict with python-ipmi
19:20:14 <NobodyCam> I think the rename is done
19:21:00 <NobodyCam> no jbjohnso
19:21:13 <NobodyCam> any questions on the rename?
19:21:59 <NobodyCam> ok next up Fix for recursive-driver-import problem
19:22:11 <NobodyCam> it also is done
19:22:13 <lucasagomes> seems to be fixed as well
19:22:24 <lucasagomes> I think we should remove those from the agenda
19:22:27 <NobodyCam> I will remove both from agenda
19:22:40 <NobodyCam> ok then
19:22:47 <NobodyCam> #topic API discussion
19:23:15 <NobodyCam> and our epic story
19:23:36 <NobodyCam> #link https://review.openstack.org/42690
19:23:44 <NobodyCam> put vs patch
19:23:47 <NobodyCam> :-p
19:24:03 <NobodyCam> I think its now clear we need both
19:24:41 <lucasagomes> NobodyCam, yup yea so we are using both
19:24:47 <romcheg> Agree
19:24:47 <lucasagomes> did some work on it at the end of today, there's a bit more to do on the db side
19:25:11 <NobodyCam> :) awesome lucasagomes
19:25:14 <lucasagomes> basically the way we are updating the resources currently doesn't allow us to delete them (set it to None for e.g), with patch we should be able to do it
19:25:27 <NobodyCam> :)
19:25:27 <lucasagomes> so i will try to work a bit on that
19:25:39 <NobodyCam> :)
19:25:55 <NobodyCam> questions / comments?
19:26:25 <NobodyCam> ok ... missed this one last week... API response code support in Pecan/WSME
19:26:59 <lucasagomes> I think, it was fixed in trunk
19:27:06 <romcheg> AFAIR yes
19:27:12 <NobodyCam> :)
19:27:21 <NobodyCam> ok then weill remove that one too
19:27:31 <lucasagomes> #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/013456.html
19:27:42 <NobodyCam> :)
19:27:57 <NobodyCam> vendor_passthru: return values and HTTP methods allowed for this resource
19:28:12 <NobodyCam> lucasagomes: you had some thoughts on this
19:28:27 <lucasagomes> ok vendor_passthru... last week we agreed on how it will look like in the API side
19:28:32 <NobodyCam> yuriyz: you still around?
19:28:44 <yuriyz> should we pass node_id or node_obj from api?
19:29:14 <romcheg> yuriyz: I think an id should be sufficient.
19:29:14 <lucasagomes> we basically decided that clients will do something POST '{"foo": "bar"}' /nodes/1/vendor_passthru/<method>
19:29:26 <lucasagomes> where method doesn't exist in the api code
19:29:43 <yuriyz> ok i agree
19:29:45 <lucasagomes> yuriyz, id, with the id u can get the obj
19:29:50 <lucasagomes> if needed
19:30:02 <lucasagomes> ok some thoughts about it
19:30:13 <lucasagomes> which HTTP method should be allowed by this resource?
19:30:13 <NobodyCam> the obj thing was me
19:30:25 <yuriyz> and return?
19:30:28 <lucasagomes> only POST? POST/PUT? GET as well?
19:30:32 <NobodyCam> id is what we should pass
19:30:54 <yuriyz> post must be in this list
19:31:17 <romcheg> POST should be sufficient
19:31:19 <lucasagomes> anyone see any use for GET in this method?
19:31:38 <lucasagomes> romcheg, +1 in the moment I only see use for POST
19:31:45 <NobodyCam> not off the top my head
19:32:12 <romcheg> I think we can always allow other methods, if they are required
19:32:18 <lucasagomes> romcheg, +1
19:32:22 <NobodyCam> +1
19:32:25 <lucasagomes> so I will allow POST-only for now
19:32:31 <lucasagomes> later if needed we add more
19:32:39 <yuriyz> and rpc side? general 'notify' or single 'passthru' method?
19:34:17 <NobodyCam> we are set up for the single passthru
19:34:19 <NobodyCam> ?
19:34:25 <yuriyz> agree
19:35:07 <NobodyCam> any more Q / C?
19:35:12 <lucasagomes> yes
19:35:16 <NobodyCam> :)
19:35:20 <lucasagomes> what should it return?
19:35:27 <lucasagomes> if it's async and we are retuning a 202
19:35:41 <lucasagomes> we should return some object that would allow the client to monitor that request
19:36:28 <lucasagomes> yuriyz, any thoughts?
19:36:40 <lucasagomes> I see ur calling cast here: https://review.openstack.org/#/c/41976/3/ironic/conductor/rpcapi.py
19:37:53 <yuriyz> I will wait your API patch
19:39:10 <NobodyCam> I need to look at that one more closly
19:39:21 <lucasagomes> hmm I see, but we need to try to find out
19:39:30 <lucasagomes> if I should wait for a return value
19:39:46 <yuriyz> i think no
19:40:04 <lucasagomes> or should just call it and return something like 202 and say that the request is fine but it async so there's no ret value
19:40:09 <lucasagomes> ok
19:40:26 <yuriyz> +1
19:40:26 <lucasagomes> and how the user would monitor if the request was complete ?
19:40:29 <NobodyCam> lucasagomes: ya
19:40:32 <romcheg> +1 ащк 202
19:40:36 <romcheg> *for
19:40:48 <NobodyCam> +1 -> 202
19:40:51 <NobodyCam> :)
19:41:08 <yuriyz> and 'method' should be a parameter?
19:41:17 <yuriyz> in rpc
19:41:24 <lucasagomes> yuriyz, IMO yes
19:41:30 <yuriyz> agree
19:41:34 <lucasagomes> I would separete method and data
19:42:04 <yuriyz> yes, data is vendor specific
19:42:08 <NobodyCam> +1
19:42:11 <lucasagomes> so that means that we are not introspecting the user data at all
19:42:21 <lucasagomes> we are just passing the same data the client send us to the driver
19:42:29 <lucasagomes> without touching/looking at it at all
19:42:32 <NobodyCam> yes!
19:42:46 <yuriyz> only driver should veryfy data
19:42:51 <lucasagomes> yea
19:43:22 <NobodyCam> :)
19:43:47 <lucasagomes> any other q / c?
19:43:52 <NobodyCam> hehehe :-p
19:44:24 <NobodyCam> ok then moving on to: Food For Thought / open discussion
19:44:38 <NobodyCam> #topic open discussion
19:45:05 <NobodyCam> I staated to see some questions about ironic and networking
19:45:12 <romcheg> Did we make any plans regarding to networking/
19:45:44 <romcheg> We have a bunch of folks here who are interested in making Ironic work with neutron
19:45:50 <NobodyCam> um .. cough ...
19:45:53 <lucasagomes> hehe
19:46:15 <NobodyCam> romcheg: bring them over.. I think we will need to do that
19:46:24 <romcheg> My concern is that we didn't have any discussions on that
19:46:47 <NobodyCam> thats why I put up the FFT section
19:47:10 <romcheg> I can bring them to #openstack-ironic tomorrow.
19:47:25 <romcheg> Do we need to wait for devananda to discuss this?
19:47:34 <lucasagomes> what's the story with neutron and pxe boot?
19:48:15 <NobodyCam> I think we can start to discuss but prob want to wait for input befor3 we get into real work
19:49:37 <NobodyCam> lucasagomes: how will ironic attach to different networks to boot clients
19:49:41 <romcheg> lucasagomes: we need at least to configure networking to let the node to access ironic node for pxe-boot
19:50:07 <NobodyCam> dkehn: any thought on this topic???
19:50:07 <lucasagomes> I found an old email threat about quantum + nova bm + pxe boot
19:50:07 <lucasagomes> http://lists.openstack.org/pipermail/openstack-dev/2013-January/004267.html
19:50:48 <dkehn> hmm, still thinking
19:51:09 <dkehn> this is going to be a longer sdiscussion
19:51:40 <NobodyCam> also can you #link your current reviews
19:51:48 <romcheg> If we're done on networking, I have also a question on DB :)
19:51:59 <NobodyCam> romcheg: shot
19:52:04 <dkehn> but your going to have to configure it in /etc//nova/nov.conf and then have the https://review.openstack.org/#/c/30441/ and https://review.openstack.org/#/c/30447/ patches in placew
19:52:11 <NobodyCam> this is open floor
19:52:18 <romcheg> Now we use migrations to initialize a DB
19:52:56 <romcheg> Since we didn't have any released packages, we can use models to create the new DB
19:53:10 <yuriyz> and my last patch demonstrate models != migrations
19:53:33 <romcheg> yuriyz: yes, that's the biggest problem of this approach
19:54:50 * NobodyCam notes 5 minutes
19:55:06 <NobodyCam> Ty dkehn
19:55:16 <jdob> so the current approach is to apply all of the migrations in order to build up the DB from scratch?
19:55:33 <romcheg> jdob: yes
19:55:38 <NobodyCam> yes db-sync
19:56:38 <jdob> the benefit to that is that, a few releases down the road, it's more likely a new install will look like an upgraded one. my concern is that if models != migrations, a 1.5 fresh installation will look different than one upgraded from 1.x
19:56:49 <jdob> "benefit to using migrations" that is
19:57:16 <jdob> if there's drift between the model and migrations, long term there's potential for maintenance headaches on upgrades
19:57:34 <NobodyCam> jdob: I tend to agree with migrations
19:58:50 <NobodyCam> ok getting close to the bell
19:59:05 <lucasagomes> :)
19:59:11 <NobodyCam> any thing left we can take to our regular channel
19:59:49 <NobodyCam> oh then
19:59:57 <NobodyCam> ok then *
20:00:07 <NobodyCam> thank you all for a great meeting
20:00:12 <lucasagomes> np :)
20:00:15 <NobodyCam> #endmeeting