05:02:43 #startmeeting ironic 05:02:44 Meeting started Tue Mar 3 05:02:43 2015 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:02:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:02:47 The meeting name has been set to 'ironic' 05:02:48 devananda: or do you mean the fact that we use xen :P 05:02:52 * jroll stays on topic 05:02:54 #chair NobodyCam 05:02:55 Current chairs: NobodyCam devananda 05:03:11 as always, the agenda can be found on the wiki here 05:03:13 * rameshg87 wonders whether NobodyCam is around 05:03:18 #link https://wiki.openstack.org/wiki/Meetings/Ironic 05:03:34 #topic announcements 05:03:53 si I am 05:03:53 only announcement on my end -- feature proposal freeze is this week 05:04:17 I expect much of today (and tomororw) will be going over that 05:04:41 anyone else have announcements? 05:04:45 devananda: any specs we want to try to land for that? 05:05:00 maybe - let's cover that after announcements 05:05:07 also - FPF shouldn't actually be an announcement 05:05:17 that's been planned for the whole cycle :) 05:05:27 devananda: :) 05:05:29 ok - moving on to status reports 05:05:34 #topic subteam status reports 05:06:11 light reports this week, people must be slacking :) 05:06:16 for those that updated the etherpad already, thanks much 05:06:19 #link https://etherpad.openstack.org/p/IronicWhiteBoard 05:06:38 since I dont see dmitry here, i'll post his update 05:06:42 * jroll just realized IPA has updates 05:06:44 (As of Mon, 02 Mar 17:00 UTC) Open: 129 (-7). 3 new (-4), 32 in progress (-4), 0 critical, 18 high and 7 incomplete 05:06:59 I think you guys might be running over... ? 05:07:14 mrda: ? 05:07:16 ?? 05:07:23 Sorry, mea culpa 05:07:28 :) 05:07:34 mrda: :) 05:07:34 (damn scrollback!) 05:07:54 always page down when your question feels out of place :P 05:08:10 also of note, a security issue was found and fixed last week 05:08:14 * devananda annotates it on the 'pad 05:08:48 #link https://launchpad.net/bugs/1425206 05:08:49 Launchpad bug 1425206 in OpenStack Security Notes "Setting debug mode also causes Pecan to run in debug mode" [Undecided,New] 05:08:58 thanks, jroll 05:09:02 * naohirot I just updated iRMC in the white board. 05:09:08 naohirot: cheers, ty 05:09:15 thank you naohirot 05:09:31 naohirot: iRMC has a pxe-based deploy driver already landed, right? 05:09:44 devananda: NobodyCam: you are welcome 05:09:47 * rameshg87 notes jroll forgot to update ironic.conf.sample :) 05:09:50 folks can feel free to ping devananda or myself if you have questions about that bug, but it isn't particularly horrible in most cases 05:10:03 rameshg87: shh :P 05:10:03 devananda: Yes, it has been landed. thanks! 05:10:19 jroll, :) 05:12:26 great, thanks for all the updates there 05:12:45 #topic kilo-3 05:13:01 we could probably talk about this for a long time 05:13:23 i'll time-box us to 30 minutes though :) 05:13:45 tldr; we have a tonne of specs already approved 05:13:50 devananda, i guess there are many driver-related stuffs waiting this time in kilo-3 05:13:52 #link https://launchpad.net/ironic/+milestone/kilo-3 05:13:57 yes 05:14:08 some, but not all of them, require changes in the core code 05:14:14 eg, all the cleaning & zapping work 05:14:43 rameshg87: by the way, thank you for the excellent email on the benefits of working out-of-tree 05:14:51 devananda, :) 05:15:02 enough of cleaning should have landed today for everyone to base their code on (hopefully!) 05:15:12 JoshNang: fantastic! 05:15:19 JoshNang: how much // what is left? 05:15:24 JoshNang, and zapping, are you working on that ? 05:15:33 #info JoshNang> enough of cleaning should have landed today for everyone to base their code on (hopefully!) 05:15:34 JoshNang, i have my specs dependent on zapping :) 05:15:49 devananda: the actual execution of the cleaning code, the api, and zapping api 05:16:14 plus the agent bits (mostly ready in IPA, needs driver support) 05:16:18 JoshNang: can you update the status of those BP then? they say "started" right now 05:16:25 sounds like they are further along than that? 05:16:27 :/ oh, yeah 05:16:32 ty 05:16:50 rameshg87: as far as zapping, you should be able to go, as the @clean_step decorator should be all you need 05:16:51 BadCub and I will be watching the milestone page closely 05:17:09 so if a BP is assigned to you, please keep it up to date regularly over the next month 05:17:50 JoshNang, yeah i understand, but i need some more info on how inband zapping steps are planned (like getting the ramdisk booted and such stuffs) 05:18:24 JoshNang, any examples of agent zapping task on your private github might help as well 05:18:26 rameshg87: ahh gotcha. my plan is to have it all the clean/zap reviews up by end of the day thursday 05:18:29 naohirot: irmc virtual media deploy driver is marked "blocked" right now -- I see code, some of which has landed 05:18:47 naohirot: is either the spec or code waiting on anything at this point (besides reviews) ? 05:19:15 JoshNang, okay. let me know if i can help with something on the zapping if that will speed it up :) 05:19:29 JoshNang, i will be happy to try to help :) 05:19:45 rameshg87: we haven't really used zapping yet :/ and downstream we just always have an agent booted. i might take you up on that :) 05:19:58 naohirot: ooh. I see. there is still disagreement on the architecture around the driver mounting NFS shares 05:20:28 JoshNang, ah okay .. here we might need to get the agent booted when the node is in manageable state. will discuss on that when you have time 05:20:40 devananda: No, both are not waiting for anything, both are independent, i thinks. 05:20:44 naohirot: given the other project proirities, i'm going to untarget that at this point because there is still contention on the design 05:21:45 devananda: I understand the situation, I'm going to contribute reviewing high priority feature 05:22:20 devananda: And later if we had some space, please consider iRMC virtual media :) 05:22:38 naohirot: thank you. I think it also poses a good question for us -- should drivers, in their constructor, take administrative actions on the host, like mounting NFS or asserting that tftpd is running? 05:22:43 in the past the answer's been "no" 05:23:09 naohirot: definitely. I like the feature but I can understand the objections people have raised 05:23:29 we've got one other blocked BP up here 05:23:42 yeah, localboot 05:23:46 yea 05:23:47 which doesn't appear to be blocked 05:23:48 https://blueprints.launchpad.net/ironic/+spec/local-boot-support-with-partition-images 05:23:53 right ... 05:23:59 if it's blocked, it's blocked on DIB or IPA :P 05:24:06 devananda, and https://blueprints.launchpad.net/ironic/+spec/inband-raid-configuration 05:24:10 devananda, inband raid configuration 05:24:12 devananda: really, some core member has some objection regarding NIF/CIFS? 05:24:18 devananda, that has dependency on the zapping implementation 05:24:27 naohirot: yes, it's on the review 05:24:48 though this isn't the place/time to discuss that... 05:24:51 devananda, i would say it's a dependency, not that it's blocked :) 05:25:11 rameshg87: ahh, right 05:25:30 rameshg87: what's your sense -- will there be time to land inband raid config this cycle, with zapping still in the works? 05:25:39 (my sense is "no") 05:25:40 devananda, ironic-python-agent is going through some refactoring on zapping space - so JoshNang asked to wait 05:25:47 ok 05:25:57 jroll: If so, I wanted to discuss earlier, I thought I've already answered some of questions. 05:26:04 devananda, inband doesn't have much code - all is done in proliantutils - with ipa hardware manager 05:26:17 yeah, we landed the multiple hardware managers bit, which through a wrench in my previous patches 05:26:19 devananda, ironic is just triggering it - just like any other agent cleanup/zap task 05:26:20 rameshg87: that's out of band 05:26:37 *threw 05:26:41 rameshg87: out-of-band means via the BMC. in-band means via the ramdisk (IPA + local utilities) 05:26:56 devananda, yeah, it's in-band 05:26:57 JoshNang: heh. so punt on in-band until L* ? 05:27:02 * naohirot s/some of questions/all of questions/ 05:27:04 naohirot: I'm looking at patchset 22, it doesn't appear resolved. I think y'all should debate it more in gerrit/mailing list/irc. 05:27:06 devananda, ilo can't do raid configuration out of band 05:27:15 rameshg87: oh! 05:27:18 devananda, so we choose to do it from agent ramdisk - and implementation is in hardware manager 05:27:19 naohirot: "I think this way is better" is not an answer. 05:27:33 devananda: hmm hopefully not. i just need to refactor a bit. i might enroll some help from other IPA people for that 05:27:47 rameshg87: I thought that it could do out-of-band. sorry 05:28:04 devananda: JoshNang: to be clear, "refactor" here means re-write existing patches to IPA 05:28:13 devananda, yeah, it's only in-band for ilo. so the code in ironic is just to trigger the in-band thing through ipa 05:28:53 gotcha 05:28:55 jroll: probably half of it, the calling and listing steps bit 05:29:00 * devananda refrains from retargeting that 05:29:10 jroll: I'm wondering that there is no comments on patch #22 05:29:29 naohirot: we are talking about https://review.openstack.org/#/c/134865/ correct? 05:30:17 jroll: Yes, it is. it's iRMC virtual media deploy spec. 05:30:47 naohirot: I see comments on patch 22; not inline, just comments. 05:31:00 any other specs or BPs folks wnat to talk about now? 05:31:07 naohirot: anyway, I don't think we should spend the whole meeting talking about that spec, let's discuss later. 05:31:32 jroll: Okay 05:31:55 actualy i do 05:32:05 devananda, get/set boot mode spec still needs approval 05:32:38 https://review.openstack.org/#/c/151596/ 05:32:46 wanyen: link? 05:33:12 link : https://review.openstack.org/#/c/129529/ 05:33:12 https://review.openstack.org/#/c/129529/ 05:33:12 thats for the ilo-properties-capabilities-discovery 05:33:40 NobodyCam: Its for Add get/set boot mode to Management Interface 05:34:07 your link or mine? 05:34:16 also, need reviewers for uefi secure boot (no core reviewers review it yet) 05:34:17 stendulker: mine 05:34:17 one thing at a time... 05:35:00 wanyen: ah 05:35:08 so- I'm of the opinion we shouldn't land any more specs, personally 05:35:20 but if something is SUPER important I guess we could 05:35:28 jroll: fwiw, I think we already have far too many to actually finish them all 05:35:37 jroll: but that's what I'm trying to find out :) 05:35:40 devananda: agree, which means more is worse 05:35:43 +1 05:36:12 without digging into it deeply yet, this is relatively small and might be something we want to land now 05:36:15 https://review.openstack.org/#/c/129529/6/specs/kilo/add-boot-mode-mgmt-interface.rst,cm 05:36:23 since we just added a lot of similar things this cycle 05:36:47 yeah, seems fine 05:36:50 * jroll quickly reviews 05:37:06 my only concern there is impact to existing drivers // drivers that can't support it 05:37:24 (I thought this was already landed) 05:37:26 devananda, to clarify, no core reviewers review uefi secure boot code yet https://blueprints.launchpad.net/ironic/+spec/uefi-secure-boot 05:37:40 jroll: that should make your vote easy to cast :) 05:37:44 devananda, the secuer boot spec has been approved. 05:37:59 wanyen: we're very busy, we will get to it. 05:38:06 jrol, ty 05:38:15 wanyen: ok. we're focusing on specs and blueprints right now, not code reviews. 05:38:23 s/jrol/jroll 05:38:48 (now == this meeting) 05:39:05 devananda, only concern we had regarding that get-set boot mode was whether boot mode should have it's own get/set methods or not 05:39:18 devananda, that was rloo's concern 05:39:24 rameshg87: I see this now says that there's no REST API change 05:39:33 devananda, yeah it doesn't have 05:40:03 rameshg87: what calls these methods then? 05:40:06 rameshg87: what's the alternative to that? 05:40:07 devananda, wherever we are getting/setting boot mode in place, just a request to make it part of an interface 05:40:25 devananda, we are doing get/set boot mode in ilo driver deploy right now 05:40:34 rameshg87: it needs to be called somehow OUTSIDE of the driver though 05:40:45 jroll, alternative to that was to have a generic method which can get/set any capability - and boot_mode is one of them 05:40:47 a) some external event triggers it one way or another 05:40:52 devananda, iLo health sensor spec https://review.openstack.org/#/c/127378/ still need to be approved 05:41:05 b) if that is done for drivers which don't support it, how will UnsupportedDriverExtension be handled? 05:41:08 stendulker: its required to prepare the pxe config as well based on boot mode 05:41:29 devananda: essentially this will s/ilo_utils.set_boot_mode/driver.management.set_boot_mode/ 05:41:30 devananda, we don't call get/set boot mode from outside right now (no api for that) 05:41:31 AIUI 05:41:39 jroll, exactly 05:41:42 jroll: oh 05:41:48 rameshg87: ok. that makes no sense to me 05:42:00 rameshg87: we need get boot mode in pxe 05:42:13 rameshg87: if there's no need for a REST API and nothing outside of the driver needs, it, why make it part of the driver API ? 05:42:36 devananda, it's not something needed right now 05:42:38 so, I posted this in gerrit: if only iLO is using this, why standardize on an interface for it? 05:42:45 this might be the same question devananda had 05:42:49 jroll: ++ 05:43:03 Fyi Timebox 30 Minutes is up.. 05:43:06 ok - I'm going to copy this conversation to gerrit and let's revisit this in Liberty 05:43:09 NobodyCam: thanks 05:43:10 jroll, yeah drivers can use this later - that was intention of that spec 05:43:16 devananda, okay 05:43:29 cool 05:43:38 rameshg87: driver API should only be changed when there is a clear need for multiple drivers, and they can agree upon a standard 05:43:43 never pre-emptively 05:43:59 devananda, okay 05:44:21 rameshg87: i'm happy to explain more on that, and should probably write a blog post on it or something .... anyway ... 05:44:30 this was also stendulker's agenda item yes? 05:44:35 #topic open discussion 05:44:37 jroll: was it? 05:44:42 I believe so 05:44:42 that seems separate 05:44:45 jroll, no 05:44:48 jroll, it's separate 05:44:51 wow, not at all 05:44:54 stendulker: your item is about elilo vs. grub2, 05:44:56 right? 05:45:00 ok, I mis-remembered, had to look again 05:45:06 thanks devananda 05:45:17 this is more of a heads-up on change of uefi boot loader 05:45:23 We need grub2 to support secure boot feature. Linux vendors supply signed grub2 binaries with their distribution 05:45:28 elilo is not signed by any linux vendors. 05:45:36 hence its proposed to change the uefi bootloader to grub2 as part of https://review.openstack.org/#/c/154808/ 05:46:03 Nisha: ran in to a issue with the ilo discovery deleting a port from a reserved node would love to get eyes on the fix: https://review.openstack.org/#/c/151596/24/ironic/db/sqlalchemy/api.py 05:46:06 stendulker: what parts of ironic does this affect? 05:46:14 devananda: jroll: regarding iRMC spec, it's not a contention which Demitry commented, because he gave +2. I thought it was just a suggestion. 05:46:21 devananda: uefi deploy 05:46:59 naohirot: Dmitry Tantsur 05:46:59 Feb 3 11:46 PM 05:47:02 -1 05:47:03 stendulker: so far only pxe‎_ilo driver was supporting uefi, but in K-release it seems many other drivers would be supporting uefi 05:47:12 oops - bad paste 05:47:16 naohirot: Patch Set 21: Code-Review-1 05:47:22 devananda: hence thought of bringing this up in the meeting 05:47:38 devananda: sorry, s/Demitry/Dmitry/ 05:47:39 naohirot: he gave a +2 in patchset 7, that's completely unrelated 15 patchsets later 05:48:27 stendulker, pxe_ipmitool also support uefi deploy (just that setting boot device fails) 05:48:27 stendulker: partition-based deploys only? or does this affect all deploys because it affects the deploy ramdisk itself? 05:48:56 naohirot: it *is* a contention, you have at least two cores and two regular contributors that have pointed out this issue. 05:49:04 devananda: partition based 05:49:25 devananda: I could nt gets secure boot enabled disk image to test it out though 05:49:31 stendulker: k, thought so 05:49:38 stendulker: oh... that's surprising 05:49:53 jroll: Patch Set 21: Code-Review-1 that was his misunderstanding, I answered to him 05:49:58 stendulker: don't some cloud providers already produce uefi-capable cloud images? 05:50:23 naohirot: it does not seem that way to me, it's a -1 with clear concerns 05:50:29 devananda: coreos provides dis images but they are just uefi ones 05:51:04 devananda: not sure if they are signing them with their own digital sign and not using Microsoft digital signature 05:52:00 devananda: Other vendors like ubuntu, fedora and redhat supply microsoft signed shim bootloader and grub2 with teir own signatures 05:52:11 jroll: yeah, if there is still concern we can discuss. but I'd like to know what kind of concern is it? 05:52:32 naohirot: I have posted on the spec. let's discuss later 05:52:55 naohirot: I've also posted on the spec, if it's not clear please ask me after the meeting 05:53:04 devananda: okay, let's discuss in the channnel. 05:53:33 stendulker: interesting. well - as you proceed, please share documentation on testing and using it 05:54:00 devananda: sure. Have already raised review for DIB changes to accomaodate this 05:54:19 devananda: link https://review.openstack.org/#/c/153987 05:54:57 #info locally-bootale partition-based deploys need grub2 to support UEFI-boot 05:55:10 #link https://review.openstack.org/#/c/153987 05:55:18 devananda: and pxe-bootable, if I'm reading that change correctly? 05:55:49 stendulker: oh! does this also affect net boot? 05:55:57 looking at https://review.openstack.org/#/c/154808/17/ironic/drivers/modules/pxe_grub_config.template 05:55:59 hard to tell 05:56:33 devananda: Since netboot is just a kernel parameter, it can be accomodated 05:57:05 devananda: kernel parameter passed into bootloader config file 05:57:10 that seems odd. grub shouldnt be involved in pxe boot... 05:57:29 yeah, I thought I was just learning something new today 05:57:32 but I'm skeptical 05:57:44 stendulker: you're configuring grub to boot from network? 05:57:50 that's fascinatingly backwards :) 05:58:01 devananda: we need to have a bootloader into tftpdir to support pxe-boot, right? 05:58:07 log.warn(_LW("2 minutes to go.")) 05:58:12 NobodyCam: lol, nice :) 05:58:17 NobodyCam: :) 05:58:19 :) 05:58:20 lol 05:58:28 devananda: yes 05:58:43 NobodyCam: I think that should be at info level, -1 05:58:47 devananda: just as we do it for elilo today 05:58:59 stendulker: neat. I need to think more about that 05:59:10 lol 05:59:26 log.error in t-30 seconds 05:59:35 my initial reaction is that that's crazy .... but I dunno 05:59:37 devananda: ok. Please have a look at https://review.openstack.org/#/c/154808/ 05:59:41 will do 05:59:53 thanks, all! 05:59:56 see you tomorrow :) 06:00:02 Thank you all 06:00:04 bye, good night:) 06:00:05 devananda: thank you 06:00:05 thanks deva :) 06:00:06 Ciao! 06:00:10 thanks 06:00:10 #endmeeting