19:00:51 <devananda> #startmeeting ironic
19:00:51 <openstack> Meeting started Mon Apr  7 19:00:51 2014 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:52 <linggao> \o
19:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:55 <openstack> The meeting name has been set to 'ironic'
19:01:00 <max_lobur> o/
19:01:14 <devananda> #link agenda: https://wiki.openstack.org/wiki/Meetings/Ironic
19:01:21 <devananda> as usual, our agenda is posted there
19:01:22 <matty_dubs> \o
19:01:23 <GheRivero> o/
19:01:26 <yuriyz> o/
19:01:42 <rloo> o/
19:01:47 <agordeev2> o/
19:01:52 <NobodyCam> :)
19:01:53 <devananda> with icehouse closed and the summit coming up, there's not a lot specifically on the agenda
19:01:53 <lucasagomes> wow lots of ppl :D
19:02:03 <devananda> so hopefully we'll have plenty of time for open discussion
19:02:14 <devananda> #topic icehouse backport potential
19:02:17 <devananda> #link https://bugs.launchpad.net/ironic/+bugs?field.tag=icehouse-backport-potential
19:02:31 <devananda> last week, two bugs were tagged as backport potential
19:02:49 <devananda> if folks are there any other bugs taht folks have found that they feel should be back ported?
19:03:08 <NobodyCam> well
19:03:10 <devananda> *are there bugs that ...
19:03:37 <NobodyCam> I haven't filed one but https://review.openstack.org/#/c/85529
19:03:44 <romcheg> devananda: I remember a patch that enabled gpt support for icehouse
19:04:31 <NobodyCam> seems the nodes in gates testing are left on!
19:04:43 <aburaschi> o/
19:04:57 <devananda> NobodyCam: i think lifeless posted to the ML about this? (it's in my queue to read after the meeting)
19:05:12 <NobodyCam> ack
19:06:38 <devananda> ok, i'll look into that after the meeting. I see what the patch is doing, but not sure what the bug is
19:07:02 <devananda> romcheg: https://review.openstack.org/#/c/84396/ ?
19:07:25 <romcheg> devananda: Oh, yes, thanks
19:07:58 <romcheg> #link https://review.openstack.org/#/c/84396/
19:08:04 <devananda> ok, if there are any other critical bugs, pls bring up in channel. let's land fixes for those and I'll back port later this week
19:08:07 <devananda> moving on ...
19:08:13 <lucasagomes> that's a fix for the swap >= 1024MB
19:08:34 <devananda> #topic integration testing
19:09:09 <NobodyCam> O am still working on getting the undercloud test going
19:09:35 <devananda> adam_g: hi! are you around / any news to share on tempest in the gate?
19:09:37 <adam_g> still hitting and fixing bugs in tempest that are preventing a 100% passing job for us. most recentlky with some FWAAS tests that were merged last week
19:09:40 <devananda> :)
19:10:12 <adam_g> ironic+devstack+tempest requires we run the suite without isolated tenant credentials (a single tenant), which is not something that is tested often enough in the normal tempest gate
19:10:27 <devananda> so it is worth calling out to folks that, at this point, the check-tripleo-ironic-seed-precise test should be considered voting
19:10:38 <NobodyCam> i have a patch up to TripleO-element to correct our logging.
19:10:41 <NobodyCam> #link https://review.openstack.org/#/c/85455
19:10:50 <devananda> if yousee a failure from check-tripleo-ironic-seed-precise, please look into it and don't approve the patch
19:11:12 <lifeless> NobodyCam: seed should turn them off I think?
19:11:50 <lucasagomes> devananda, +1 yeah I'm looking into these checks already, trying to not break it
19:11:52 <NobodyCam> lifeless: ok I had put up a wip review to handle in ironic
19:11:55 <adam_g> oh! we will soon have the nova code's unit tests running in the gate: https://review.openstack.org/#/c/84033/
19:12:16 <devananda> adam_g: interesting. so single-tenant is breaking things not related to ironic or nova?
19:12:35 <adam_g> devananda, yes--they are valid bugs in tempest that are fixable, just taking some time
19:12:56 <adam_g> https://bugs.launchpad.net/tempest/+bug/1302942 is the most recent
19:12:57 <devananda> adam_g: gotcha. thanks for tackling those!
19:12:58 <uvirtbot> Launchpad bug 1302942 in tempest "fwaas tests are racey" [Undecided,In progress]
19:13:11 <devananda> lucasagomes: re your comments on https://review.openstack.org/#/c/84033/ about moving the nova driver back to nova ...
19:13:35 <lucasagomes> yeah I talked to NobodyCam a bit in the #openstack-ironic channel
19:13:56 <lucasagomes> I was mostly concerned about having to add dependencies to ironic (e.g mox) just because of the nova driver
19:14:25 <lucasagomes> so as juno opened I thought about trying to get it in nova asap, instead of keep using the ironic tree to develop the driver
19:15:17 <devananda> lucasagomes: i discussed this a bit with russellb last week. tldr; it's up to nova team, and there needs to be some larger discussions before they'll accept it AND let our tests vote
19:15:23 <devananda> so I proposed this session for Atlanta
19:15:24 <devananda> #link http://summit.openstack.org/cfp/details/215
19:15:59 <devananda> so we can all discuss the challenges in Ironic having a hard depdency on an internal API of Nova's, while we need to maintain asymmetric gating ...
19:15:59 <lucasagomes> devananda, ah great, yeah I think the soon we iron it out the better
19:16:14 <devananda> yep
19:16:27 <devananda> and we need to continue the testing in our tree until then
19:16:32 <lucasagomes> good stuff :) /me reading the session description
19:16:47 <devananda> looks like NobodyCam just dropped offline ...
19:17:10 <devananda> any other questions/comments on testing?
19:17:22 <NobodyCam> and I'm back
19:17:44 <agordeev2> lucasagomes: mox? i think it was deprecated for new code http://lists.openstack.org/pipermail/openstack-dev/2013-July/012484.html but IMBW
19:18:12 <devananda> agordeev2: yes - mox is deprecated, but nova has not fully removed its depenency on mox yet
19:18:15 <romcheg> agordeev2: But it's still required for the old one
19:18:24 <NobodyCam> agordeev2 its for the nova tests
19:18:30 <devananda> agordeev2: so for us to run nova's unit tests within our gate, we have had to add mox temporarily
19:18:31 <lucasagomes> agordeev, yeah, but nova still uses it in some parts :( https://review.openstack.org/#/c/84033/11/test-requirements.txt
19:19:54 <devananda> any updates on fedora support?
19:20:01 <devananda> dwalleck_: were you working on that?
19:20:22 <dwalleck_> devananda: Nope, not me
19:20:57 <devananda> dwalleck_: hm, sorry for the spam then.
19:21:05 <devananda> ok, well, moving on ...
19:21:08 <dwalleck_> But I could look into that if no one else is. Fedora support for virtual-ironic?
19:21:25 <matty_dubs> Was someone looking at it?
19:21:26 <lucasagomes> I test things on fedora... it works but I usually disable selinux
19:21:37 <lucasagomes> and have to tweak firewalld
19:21:45 <dtantsur> I was testing like 2 weeks ago, and it didn't work for me
19:21:52 <devananda> I think someone (i'm forgetting who) was looking at devstack + ironic testing
19:21:54 <rloo> someone was working on it and i thought there was an etherpad, but i don't recall where...
19:21:54 <matty_dubs> I think some of us run Fedora+Ironic, but I'm not sure if there are any open tasks for it?
19:22:04 <lucasagomes> that was dtantsur no?
19:22:07 <NobodyCam> lucasagomes: do we have a bug for the firewalld changes that are required?
19:22:11 <romcheg> It worked for me as well but with selinux disabled
19:22:12 <devananda> dtantsur: ah, hi! I got the first letter right :)
19:22:16 <dtantsur> We still have some patches since then  https://review.openstack.org/#/c/81770/  https://review.openstack.org/#/c/81807/
19:22:23 <lucasagomes> NobodyCam, I have to tweak it to get the dhcp working
19:22:45 <lucasagomes> NobodyCam, but, the fedora cloud image for e.g doesn't have firewalld (uses iptables instead)
19:22:56 <NobodyCam> ahh
19:23:00 <dtantsur> I also started this https://review.openstack.org/#/c/82760/ but abandoned for some time (testing instack now)
19:23:19 <devananda> if someone wants to take lead on that, I think that'd be great
19:23:47 <dtantsur> devananda, I think I can step into this again this week
19:23:59 <lucasagomes> dtantsur, nice!
19:24:07 <devananda> dtantsur: thanks!
19:24:08 <lucasagomes> would be cool if at some point we get some fedora tests in gate
19:24:16 <devananda> ++
19:24:19 <lucasagomes> go go fedora :D
19:24:19 <NobodyCam> +
19:24:35 <dtantsur> yep, without tests it's useless effort
19:24:45 <dtantsur> not completely useless, but still :)
19:25:06 <matty_dubs> Some work is being done there on the TripleO side, right? That might make it easier for us to interface with.
19:25:14 <devananda> #action dtantsur to resume work on automated testing on fedora
19:25:19 <romcheg> do we use cloud fedora cloud images on the gates?
19:25:29 <NobodyCam> ubuntu 12.04
19:25:31 <devananda> romcheg: no, openstack CI is all ubuntu precise today
19:25:36 <romcheg> whoops too many clouds
19:25:55 <devananda> so this would probably have to go into tripleo, or be a third-party CI system
19:26:17 <devananda> oh, before we move to open discussion, there's one more thing i forgot to put on the agenda, but need to bring up
19:26:24 <lucasagomes> yeah, and as matty_dubs pointe out, I think there's a work going on about it
19:26:39 <devananda> and I'd like to move on so we have plenty of time for the long list of open topics :)
19:26:49 <devananda> #topic oslo liaison
19:26:51 <NobodyCam> :)
19:26:52 <devananda> #link https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
19:27:14 <devananda> we (meaning me) havent been great at keeping up with syncing code from oslo-incubator during Icehouse
19:27:26 <devananda> a few things, like the db, were synced near the end
19:27:40 <devananda> but Oslo has asked for each project to designate someone as a liaison to keep the project in sync
19:27:51 <devananda> particularly as lots of oslo-incubator componets are being split out into new libraries
19:28:04 <devananda> so, I'd like to ask if anyone wants to volunteer for that :)
19:28:10 <NobodyCam> #link https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
19:28:15 <rloo> what is a 'core committer'?
19:28:37 <GheRivero> devananda: I can step in
19:28:39 <romcheg> devananda: Several oslo folks work in my local team so I think I can be such a guy
19:28:51 <devananda> it'll also mean  attending this session, even if it overlaps with Ironic
19:28:56 <devananda> #link http://summit.openstack.org/cfp/details/70
19:29:04 <NobodyCam> hi GheRivero
19:29:28 <devananda> rloo: "core committer" is not a proper term I'm familiar with
19:30:00 <devananda> rloo: but I suspect it means a developer actively working on the "core" of the project (as opposed to drivers, etc)
19:30:00 <matty_dubs> COuld it be a +2-wielding "core"?
19:30:11 <devananda> matty_dubs: that is specifically a "core reviewer"
19:30:14 <rloo> devananda. heh, ok. I say romcheg and gheRivero are core committers :-)
19:30:29 * dhellmann updates the terminology in the wiki
19:30:35 <NobodyCam> :)
19:30:36 <devananda> dhellmann: thanks!
19:30:40 <devananda> dhellmann: did I guess right?
19:30:52 <dhellmann> yeah
19:31:02 <devananda> romcheg: GheRivero: either one of you would be good. doesn't matter to me which, so I'll leave it to you to sort out :)
19:31:10 <dhellmann> I tend to use those terms interchangeably
19:31:15 <romcheg> devananda that is not fear :)
19:31:29 <lucasagomes> yeah both of u guys sounds good to me as well
19:31:57 <devananda> great. any questions before I open the floor?
19:32:20 <devananda> #topic open discussion
19:32:24 <lucasagomes> ok
19:32:27 <lucasagomes> quick question
19:32:27 <devananda> .. and go! :)
19:32:39 <lucasagomes> I want to promove the set_boot_device method to the core PowerInterface
19:32:42 <lucasagomes> any objections?
19:32:44 <devananda> lucasagomes: ++
19:32:52 <NobodyCam> none here
19:32:52 <romcheg> lucasagomes: +1
19:32:54 <jroll> +1
19:32:54 <GheRivero> lucasagomes: ++
19:32:57 <lucasagomes> I think that was the idea we had when we first thought about vendor_passthru
19:32:59 <JoshNang> +1
19:33:00 <matty_dubs> Will we ever support something like an APC PDU?
19:33:07 <lucasagomes> identify such methods and then promote them
19:33:13 <lucasagomes> ack, someone give me an action on it please?
19:33:15 <devananda> matty_dubs: yes. and SSH driver also does not support this.
19:33:41 <matty_dubs> Ah, so it's compatible with promotion -- not everything has to support the feature?
19:34:13 <devananda> so, my thoughts on drivers which /can't/ set boot device is that they'd have it be a no-op.
19:34:19 <NobodyCam> #action lucasagomes to promote set_boot_device to core api
19:34:19 <lucasagomes> matty_dubs, the ssh driver could support it, it just not implemented (we could edit the virsh xml and set the boot order to be network for e.g)
19:34:46 <devananda> #chair NobodyCam
19:34:47 <openstack> Current chairs: NobodyCam devananda
19:34:50 <linggao> lucasagomes, set_boot_devide is not a power function,
19:34:55 <devananda> NobodyCam: sorry :)
19:35:09 <NobodyCam> #action lucasagomes to promote set_boot_device to core api
19:35:11 <NobodyCam> heheh
19:35:38 <lucasagomes> linggao, power drivers usually has a method to set the boot order
19:35:44 <matty_dubs> Yeah, I sort of agree with linggao here. I don't _oppose_ it by any stretch, but it's not universally supported and it's not strictly a power thing.
19:35:54 <lucasagomes> linggao, right now pretty much all our power drivers does, seamicro, ipminative and ipmitool
19:36:26 <devananda> depending on platform, the change may need to be implemented differently
19:36:28 <NobodyCam> and could be hack / patched in t the ssh driver
19:36:32 <linggao> lucasagomes, I am proposing a hardware control interface that include more hw control functions,
19:36:34 <devananda> boot device is a config setting
19:36:44 <romcheg> I think that is a problem of terminology: should we assume that PowerDriver === BMCDriver?
19:36:52 <linggao> lucasagomes set_boot_device shoud belong to there.
19:37:12 <devananda> for hardware, that config is done via BMC today, but it may not always be
19:37:12 <matty_dubs> romcheg++
19:37:55 <devananda> and BMC is controlled via the power drivers today
19:38:19 <linggao> devananda, here is the proposal: http://summit.openstack.org/cfp/details/98
19:38:39 <NobodyCam> #link http://summit.openstack.org/cfp/details/98
19:38:40 <gmatefi> some boot loaders can take boot device from DHCP options or from other n/w input - not necessarily BMC-driven
19:39:07 <devananda> linggao: this would seem related to the ceilometer integration work that haomeng has been doing
19:39:17 <devananda> linggao: using IPMI to gather hardware sensor data from teh BMC
19:39:41 <lucasagomes> yeah I can see some overlap with it on #2
19:39:53 <devananda> and there may be overlap with console interface, too
19:40:03 <linggao> devananda, it is more than just data for moniroing.
19:40:42 <devananda> so perhaps i can rephrase the terminology confusion
19:40:49 <devananda> we have drivers and interfaces
19:41:03 <devananda> examples of a driver: pxe_and_ipmitool
19:41:12 <devananda> example of an interface: ipmitool.PowerInterface
19:41:38 <devananda> so perhaps we need a BMCInterface?
19:42:08 <devananda> it will be a bit complicated as different drivers may map different functions into that interface's private methods
19:42:09 <linggao> davananda, we need something like that, but with more general term
19:42:17 <lucasagomes> seems that's what linggao is proposing on that bp/session
19:42:41 <linggao> davananda, BMC is just one implementation.
19:43:08 <devananda> linggao: which is why, today, we have interfaces for different functionality
19:43:31 <linggao> devananda, yes.
19:43:31 <devananda> perhaps we should create a new ConfigInterface
19:43:41 <devananda> and put set_boot_device there
19:43:41 <lucasagomes> yeah or, ManagementInterface
19:43:56 <linggao> devananda, that's why I think set_boot_device does not belong to PowerInterface.
19:43:57 <lucasagomes> right I will give it some thought
19:44:29 <NobodyCam> very good points linggao :)
19:44:37 <devananda> it sounds like we mostly agree that set_boot_device is not actually a power function, but that it should be standardized and exposed in teh REST API
19:44:52 <linggao> devananda +1
19:44:54 <NobodyCam> +
19:44:58 <lucasagomes> +1
19:44:59 <matty_dubs> Works for me!
19:45:50 <JayF> +1 to ManagementInterface, that's a good term for it :)
19:45:51 <gmatefi> is the internal structure, i.e. to which BaseDriver interfact connect to, affecting the externally visible API in any way?
19:46:08 <gmatefi> I mean REST API
19:47:03 <devananda> gmatefi: the REST API has specific controller classes for each interface today
19:47:06 <devananda> eg, power, provision, console
19:47:10 <devananda> gmatefi: so, yes
19:47:57 <devananda> other topics?
19:48:08 <devananda> 12 minutes left (and it's still an open floor)
19:48:08 <lucasagomes> I have another one
19:48:12 <lucasagomes> blacklist vs whitelist
19:48:21 <lucasagomes> #link https://bugs.launchpad.net/bugs/1302562
19:48:23 <uvirtbot> Launchpad bug 1302562 in ironic "Ironic needs a way to disable drivers" [High,In progress]
19:48:29 <NobodyCam> Disk partitioner: sfdisk vs parted
19:48:42 <lucasagomes> we need a mechanism to disable/enable drivers, should it be a blacklist or a whitelist... I first implemented as a blacklist
19:48:43 <boris-42> devananda *benchmarks*
19:48:56 <lucasagomes> but seems there's some arguments about having it as a whitelist
19:49:37 <jroll> I like the sound of a whitelist, fwiw
19:49:46 <NobodyCam> would white or black would be less work for the sysadmin
19:49:46 <lucasagomes> right
19:49:50 <jroll> explicit > implicit
19:49:54 <rloo> what are advs of blacklist?
19:49:57 <rloo> i like whitelists
19:50:07 <lucasagomes> yeah, after reading the bug log and specially rloo comments
19:50:08 <NobodyCam> I like black lists
19:50:13 <lucasagomes> I think whitelist would be a great thing as well
19:50:25 <jroll> NobodyCam: I think that's a moot point. sysadmins use automation. whether it's white or black, write it once and never look at it again
19:50:27 <dtantsur> whitelist make it clear that you may want to do some work to enable it (and you do - e.g. install deps)
19:50:35 <agordeev2> also devstack related one topic from me. Regarding non-standard port for ssh for testing pxe_ssh driver
19:50:46 <lucasagomes> right
19:50:48 <JayF> I prefer whitelist because in a CD environment
19:50:50 <rloo> problem with blacklist is that if there are new drivers, you have to update your blacklist.
19:50:52 <devananda> boris-42: sounds like you are volunteering :)
19:50:59 <JayF> I don't have to change the list my automation puts into place if a driver is added to ironic
19:51:01 <lucasagomes> rloo, yeah, that's a good arg
19:51:05 <boris-42> devananda yep join Rally=)
19:51:12 <lucasagomes> JayF, +1
19:51:12 <devananda> lucasagomes: whitelist with sane defaults is my preference
19:51:12 <JayF> rloo++ gmta
19:51:13 <boris-42> devananda it's actually quite simple
19:51:17 <lucasagomes> ack! so whitelist is it
19:51:21 <lucasagomes> I will change my patch
19:51:23 <boris-42> devananda to write benchmarks
19:51:25 <lucasagomes> devananda, btw
19:51:39 <lucasagomes> so as a whitelist should the fake* drivers been disabled by default?
19:51:47 <lucasagomes> to have a production config as default?
19:51:57 <boris-42> devananda cause what I saw different things in other project e.g.: http://pavlovic.me/rally/glance_list.html
19:52:01 <devananda> agordeev2: non-standard ssh port was initially a precaution to avoid breaking infra's access to their own jenkins slaves
19:52:13 <devananda> agordeev2: if we're not munging ssh access on :22, then it's fine, in my opinion
19:52:23 <GheRivero> lucasagomes: +1 to disable fake drivers
19:52:36 <dtantsur> devananda, non-standard ssh port is a pita for SELinux-enabled system
19:52:48 <devananda> lucasagomes: yes. disable fake* by default, explicitly add them (if we need them) for testing (both in unit and devstack)
19:53:10 <lucasagomes> ack, sweet, thanks ppl :)
19:53:11 <devananda> dtantsur: that was specifically for the openstack infra environment, which is ubuntu precise
19:53:33 <boris-42> devananda *on that graph you see how influence duration of image list command depending on amount of images*
19:53:56 <dtantsur> devananda, ok, but devstack is _not_ only for infra; it is recommended as a way to start diving into openstacl
19:53:58 <agordeev2> devananda: is non-standard port really used?
19:54:54 <devananda> dtantsur: so, if we can fix the issue (maybe it already is -- adam_g ?) where ssh would jump onto the net bridge, then we can have it use :22 all the time
19:54:55 <adam_g> agordeev, the default is used is in the virtual-ironic job
19:55:23 <devananda> dtantsur: if not, we should add an ENV var to devstack for that, and set it in -infra's jobs to not-:22
19:55:45 <devananda> boris-42: ah. sounds super useful. I'd love tosee stats for ironic's API performance
19:55:57 <boris-42> devananda it's quite simple to make
19:56:10 <dtantsur> devananda, cool. Because this patch https://review.openstack.org/#/c/81807/ got -1 for this approach
19:56:15 <boris-42> devananda that benchmark is something like 15 lines of cod=e)
19:56:25 <boris-42> devananda btw we can make rally gate in ironic
19:56:27 <dtantsur> (patch itself only fixes consequences)
19:57:36 <devananda> dtantsur: I'll take a look
19:57:42 <adam_g> in my local devstacks, i use IRONIC_VM_SSH_PORT=22 with no issue, and i do not work around any issue where ssh jumps interfaces... but in the gate, we're working around that and using the default 2222
19:57:45 <dtantsur> devananda, thanks
19:57:48 <boris-42> devananda (and yep if somebody from ironic write benchmarks, we will help with adding rally gate)
19:57:55 <NobodyCam> ah ha Ironic is not setting the ssh port in tripleO
19:58:23 <adam_g> the ssh port reconfig predates me and im not sure why we do it at all.. as long as we are sure ssh is listening on 0.0.0.0 (the default) we shouldn't need to touch ssh at all
19:58:34 <NobodyCam> 2 minute bell
19:58:37 <devananda> adam_g: exactly
19:58:43 <agordeev2> adam_g: +1
19:58:54 <devananda> adam_g: so I added it a while back, because when I was testing (at that time) it was jumping onto the net bridge
19:58:55 <adam_g> ill give it some tests on a cloud instance similar to the gate and propose something that guts it from devstack
19:59:01 <adam_g> devananda, yeah, i remember that
19:59:02 <devananda> it could have been a bug in neutron or something else that has since been fixed
19:59:17 <devananda> but as soon as devstack finished starting up, i'd lose SSH access to the host
19:59:26 <linggao> devananda, I have a question on console support, I'll take to you on the Ironic channel.
19:59:40 <adam_g> #action adam_g to investigate removal of ssh reconfiguration from ironic + devstack
19:59:50 <devananda> #action adam_g to investigate removal of ssh reconfiguration from ironic + devstack
19:59:59 <agordeev2> devananda: https://review.openstack.org/#/c/81807/ - this patch fixes that ssh breakage
20:00:06 <devananda> linggao: thanks,
20:00:11 <NobodyCam> time
20:00:13 <NobodyCam> !
20:00:21 <devananda> great meeting, thanks everyone!
20:00:26 <devananda> #endmeeting