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