05:01:24 <NobodyCam> #startmeeting Ironic
05:01:24 <NobodyCam> #chair devananda
05:01:24 <openstack> Meeting started Tue Feb 17 05:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:01:26 <NobodyCam> #chair jroll
05:01:27 <openstack> The meeting name has been set to 'ironic'
05:01:28 <jroll> woot
05:01:29 <openstack> Current chairs: NobodyCam devananda
05:01:30 <jroll> uh oh
05:01:31 <openstack> Current chairs: NobodyCam devananda jroll
05:01:36 <NobodyCam> Welcome everyone to the Ironic meeting.
05:01:40 <Nisha> o/
05:01:43 <JoshNang> o/
05:01:44 <mrda> o/
05:01:46 <naohirot> o/
05:01:49 <jroll> I suddenly have responsibility. I don't like it.
05:01:51 <NobodyCam> Of course the agenda can be found at:
05:01:51 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
05:01:52 <jroll> \o
05:01:55 <rameshg87> o/
05:01:56 <ramineni> o/
05:02:00 <NobodyCam> #topic Greetings, roll-call and announcements
05:02:01 <NobodyCam> Roll-call: Who's here for the Ironic Meeting?
05:02:04 <faizan> o/
05:02:15 <NobodyCam> howdy all
05:02:24 <stendulker> o/
05:02:26 <rameshg87> o/
05:02:34 <NobodyCam> announcements:
05:02:55 * rameshg87 understands i should raise hands only during roll-call
05:03:01 <NobodyCam> we had  a good meetup in SF ... Thanks to rackspace for hosting
05:03:14 <mrda> Thanks SFO Rackers!
05:03:37 <jroll> :)
05:03:41 <JoshNang> \o/
05:03:46 <jroll> y'all are welcome any time, officially or not
05:03:57 <jroll> I promise to have working internet next time
05:04:02 <mrda> lol :)
05:04:27 <NobodyCam> Devananda may be lurking, but I expect he's mostly still recovering from travel plage
05:04:32 <NobodyCam> moring mrda
05:04:54 <mrda> afternoon here now :)
05:05:05 <devanand_> o/
05:05:10 <NobodyCam> another announcement: we have lots of code that needs reviewing
05:05:13 <NobodyCam> for k#
05:05:23 <NobodyCam> k3 even
05:05:44 <jroll> indeed
05:05:52 <jroll> #link https://launchpad.net/ironic/+milestone/kilo-3
05:06:02 <jroll> so much code
05:06:50 <NobodyCam> and about a mounth to land it all
05:06:53 <NobodyCam> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
05:07:11 <NobodyCam> :)
05:07:28 <mrda> focus focus focus
05:08:05 <rameshg87> NobodyCam, some  blueprint's (merged spec) target need to set
05:08:13 <naohirot> NobodyCam: jroll: devanand_ : I'm really interested in the review statuses which were originally planned kilo-2
05:08:30 <rameshg87> NobodyCam, for example https://github.com/openstack/ironic-specs/blob/master/specs/kilo/ironic-generic-raid-interface.rst
05:08:33 <NobodyCam> :) so the more eyes the better... focus on functionality nit can be addressed in followup patches
05:08:41 <naohirot> NobodyCam: such as ATM, non-glance, and iRMC etc.
05:08:58 <jroll> rameshg87: when devanand_ is no longer sick, please poke him to do that
05:09:06 <jroll> naohirot: which, specifically?
05:09:07 <rameshg87> jroll, okay
05:09:31 <NobodyCam> oh I should also anouunce that we will be having someone start to track the spec/bp status starting tomorrow (for us)
05:09:37 <wanyen> Nobodaycam, I would like to add iLO node cleaning to K3
05:09:55 <mrda> NobodyCam: well, you should introduce them
05:10:00 <jroll> NobodyCam: who's that? :D
05:10:09 <NobodyCam> that would be BadCub :)
05:10:11 * jroll \o/ for a BadCub
05:10:14 <naohirot> jroll: https://review.openstack.org/#/c/134865/ and https://review.openstack.org/#/c/146803/
05:10:39 <jroll> naohirot: cool, those look targeted for k3 to me
05:10:55 <devanand_> rameshg87: BadCub can help with that, too, now
05:11:10 <NobodyCam> so starting tomorrow BadCub01_ will be going thru and ensuring everything is insync
05:11:25 <stendulker> NobodyCam: Secure boot support for iLO drivers is also a mergd spec https://review.openstack.org/#/c/135228
05:12:01 <NobodyCam> stendulker: we reviewed a couple at the meetup and then have been traveling and such
05:12:07 <naohirot> jroll: yes, but those were originally planned in kilo-2
05:12:12 <NobodyCam> so we'll be jumping into it tomorrow
05:12:34 <jroll> naohirot: right, we're aware, I think we'll prioritize those
05:12:53 <NobodyCam> ok thats it for my announcements
05:12:56 <stendulker> NobodyCam: thanks
05:13:02 <NobodyCam> anyone else have any
05:13:31 <NobodyCam> ok moving in then
05:13:45 <NobodyCam> #topic SubTeam: status report (deprecated)
05:13:54 <naohirot> NobodyCam: jroll: I'd like to know the current priority
05:14:32 <NobodyCam> naohirot: priority for?
05:14:33 <naohirot> NobodyCam: jroll: so that we can schedule tasks in each company
05:14:49 <jroll> naohirot: I mean, it's a priority for k3
05:14:54 <jroll> I don't know what to say otherwise
05:15:25 <naohirot> NobodyCam: jroll: current priority of originally planned kilo-2
05:16:00 <naohirot> NobodyCam: such as ATM, non-glance, iRMC Management driver, etc.
05:16:04 <NobodyCam> naohirot: anything not done should have been bump it k3?
05:16:14 <jroll> naohirot: right, it's a priority for K3, reviewers are aware of what was bumped to k3 from k2
05:16:22 <jroll> naohirot: not sure what else I can really say about that
05:16:56 <naohirot> jroll: I'm very afread of happing such kind of bump again in kilo-3
05:16:59 <wanyen> NobodyCam, we need both uefi secure boot and iLo secure boot to complete the secure boot feature. Can you add iLo secure boot to K3?
05:17:48 <jroll> naohirot: we'll do what we can, we only have so many reviewers and so much time
05:17:51 <jroll> we'll do our best
05:17:57 <jroll> wanyen: are the specs landed?
05:18:09 <NobodyCam> wanyen: I have a +2 on one and will review the other tomorrow
05:18:11 <wanyen> jroll, yes.
05:18:40 <jroll> wanyen: ok, talk to deva or BadCub tomorrow please
05:18:42 <NobodyCam> but first are there any questions, on the status we have on hte white board??
05:19:08 * mrda looks
05:19:30 <naohirot> jroll: I know core team is busy, so I think discussing the review priority in this meeting is important.
05:19:39 <NobodyCam> (As of Mon, 16 Feb 20:00 UTC) Open: 133 (0). 4 new (-5), 39 in progress (+5), 0 critical, 19 high (+2) and 7 incomplete
05:19:47 <jroll> naohirot: we're doing what we can :|
05:20:42 <naohirot> jroll: Yes, but I need some information to predict future to report the status to my company :)
05:20:48 <NobodyCam> ok then moving on
05:20:56 <NobodyCam> #topic Agenda items
05:21:08 <NobodyCam> (ramineni) Need Agreement on whether get/set boot mode to be part of ManagementInterface as proposed in the following spec,
05:21:16 <NobodyCam> ramineni: are you here
05:21:23 <ramineni> NobodyCam: yes
05:21:26 <NobodyCam> #link https://review.openstack.org/#/c/129529/
05:21:34 <ramineni> proposed get/set boot mode to be standardized as part of management interface as many drivers would be using it as part of deploy  in https://review.openstack.org/#/c/129529/4
05:21:41 <jroll> naohirot: that's not something I can predict, there's a good chance it will land in K3 assuming reviewers and developers are both responsive to feedback. moving on...
05:21:44 <ramineni> deva has given +1 , but no reviews after that. Not sure if everyone agrees with that
05:22:26 <wanyen> jroll, https://review.openstack.org/#/c/135845/ still need one +2 and ilo secure boot spec already merged.
05:22:31 <NobodyCam> ramineni: we have been traveling to and from the meetups I expect reviews to pick up here this weel
05:22:35 <NobodyCam> week even
05:22:44 <jroll> wanyen: getting off topic...
05:22:50 <ramineni> NobodyCam: thanks
05:23:08 <wanyen> jroll, sure.  I ws just try to clarify.
05:23:10 <jroll> ramineni: these are currently at the driver level?
05:23:50 <jroll> ramineni: at a glance I'm +1 on this
05:23:53 <ramineni> yes , currently proposed at driver level , would be good if it could be standardized , as every driver needs it
05:24:06 <jroll> ok, cool
05:24:09 <jroll> I agree :)
05:24:12 <NobodyCam> I thou I would say there was some confusion in channel about this and the https://review.openstack.org/#/c/135845/ review
05:24:52 <devanand_> Keep in mind that driver interfaces can't be partially implemented
05:25:08 <jroll> mmm, true
05:25:33 <jroll> but drivers that can't do these things could treat set_boot_device('bios') as a noop
05:25:35 <devanand_> So moving those to the mgmt interface means any driver that implements get/set boot mode must also set
05:25:52 <devanand_> Must also define the rest of the interface
05:26:12 <jroll> yeah, can assume only 'bios' is available if unsupported
05:26:18 <jroll> raise an exception for everything else
05:28:08 <jroll> anything else on this topic?
05:28:20 <NobodyCam> sorry was reading
05:28:28 <jroll> NobodyCam: I am curious what the difference is
05:28:30 <jroll> need to read more
05:28:52 <NobodyCam> I to need to take a closer look
05:28:52 <jroll> set_(secure_)boot_mode
05:28:54 <jroll> hm
05:29:19 <ramineni> jroll : you meant between two sepcs .. the latter is for enabling secure boot not boot mode
05:29:59 <jroll> right
05:30:12 <jroll> I wonder if those could be the same method
05:30:48 <ramineni> secure boot is only applicable if the machine is in uefi boot mode
05:31:20 <stendulker> jroll: They are independent, in the sense secure boot is property only of uefi boot bode
05:31:21 <jroll> hmm
05:31:33 <stendulker> jroll: /sbode /mode
05:31:42 <jroll> right, so there's three options: bios, uefi, uefi_secure, right?
05:31:58 <NobodyCam> ramineni: I think jroll is suggesting that set boot mode could do "bois" , "uefi" , "uefi Secure"
05:32:04 <NobodyCam> :0
05:32:05 <jroll> basically
05:32:26 <wanyen> jroll, only bios or uefi for set_boot_mode, secure boot is seperate
05:32:34 <NobodyCam> but lest loop back to that one
05:32:46 <jroll> wanyen: ignoring the actual method name, there's three states it could be in yes?
05:32:56 <NobodyCam> we have that still to come
05:33:18 <jroll> let's just talk about that one now/next
05:33:24 <jroll> since they're somewhat related
05:33:33 <stendulker> jroll, NobodyCam: One cannot set the uefi secure boot mode in a single API call
05:33:39 <NobodyCam> ok :)
05:33:40 <wanyen> jroll, for kilo only 3 state.  In the future, there are more uefi boot options
05:33:54 <NobodyCam> stendulker: :)
05:33:55 <devanand_> wanyen: like what?
05:33:57 <jroll> stendulker: why?
05:33:58 <NobodyCam> #link https://review.openstack.org/#/c/135845/
05:34:04 <wanyen> jroll, for instance, uefi http boot
05:34:07 <stendulker> jroll, NobodyCam: Current boot mode should be uefi to turn on secure boot
05:34:14 <jroll> wanyen: so we should make a different method for each of these modes?
05:34:16 <ramineni> yes , but secure boot is one capability which can be set only in uefi boot mode ..not sure if can be merged
05:34:30 <jroll> stendulker: why couldn't an API call to set secure boot put it in uefi mode first?
05:35:21 <jroll> I don't see why this couldn't all be one call with many modes
05:35:28 <wanyen> jroll, that's what secure boot does, if secure-boot flavor is present, ten ilo driver will setit to uefi automatically
05:35:29 <stendulker> jroll: yes, you need 2 APi calls to achieve secure boot
05:35:40 <devanand_> jroll: ++
05:35:45 <jroll> stendulker: *why*
05:36:10 <jroll> stendulker: with the code/specs proposed today, that's true. I conjecture that it does not need to be that way
05:36:23 <stendulker> jroll: first to put the node to uefi and then after reboot to turn on the secure boot
05:36:50 <devanand_> stendulker: two calls to the server, sure, but that could be underneath a single ironic API
05:36:59 <jroll> stendulker: that could still be one API call. PUT /v1/nodes/uuid/boot_mode {'target': 'uefi+secure'}
05:37:01 <jroll> or something
05:37:22 <jroll> I tend to think we should consolidate these
05:37:27 <devanand_> stendulker: wait. Why would I have to boot a server *before* I enable secure boot?
05:37:51 <jroll> get the uefi spec done, then add secure boot spec on top of it to add 'uefi+secure' to set_boot_mode
05:38:11 <stendulker> devanand_ : secure boot could be enable only if the current boot mode is uefi
05:38:15 <wanyen> jroll, we don't have an api for user to turnon secure_boot. secure_boot is turned on by flavor
05:38:56 <devanand_> wanyen: Nova passes information to ironic api to enable secure boot
05:39:13 <devanand_> So yes there is an api
05:39:23 <NobodyCam> not a cli command maybe
05:39:25 <jroll> I'm so confused as to why the operator has to do anything to make a node do UEFI or UEFI with secure boot, other than maybe flavors
05:39:51 <jroll> there shouldn't need to be a REST API to put a node in any boot mode, that should all be automatic
05:40:31 <stendulker> jroll: yes there is no REST API proposed  to put to secure boot
05:40:34 <wanyen> deva, waht I meant is that we don't have a standalone api for user to turn on secure_boot.  It is enabled as part of the nova boot, which turns into api
05:41:08 <jroll> and this is all fine
05:41:13 <devanand_> Via the /instance_info/ resource, right?
05:41:32 <jroll> I think there should be one set_boot_mode in the management interface, that can handle UEFI with or without secure boot
05:41:42 <wanyen> stendulker, I don't think user needs to call set_boot_mode uefi before nova boot with secure boot falvor. right?
05:42:04 <stendulker> wanyen: yes
05:42:36 <wanyen> jroll, basically secure boot can only be enabled by flavor.
05:42:50 <jroll> ok, that's fine
05:42:51 <NobodyCam> would like to get to faizan_'s topic so going to time box this at 5 more minutes
05:42:58 <stendulker> wan-yen: Upon getting flavor as secure_boot, in prepare stage, boot mode would be changed to uefi by the driver
05:43:01 <jroll> there should still be a management interface to set secure boot
05:43:11 <jroll> and that should be set_boot_mode('uefi+secure') or similar
05:43:16 <jroll> (imho)
05:43:23 <devanand_> Hmm. Ok, I think I see the problem. A set boot mode endpoint in the api would be duplicating other existing resources
05:43:36 * mrda notes this is an interesting discussion
05:43:36 <stendulker> and in deploy vendor-passthrough, secure boot mode would be enabled on the node
05:44:01 <wanyen> jroll, yes. uefi secure boot mgmt i/f has set_secure_boot_mode to do that
05:44:07 <jroll> devanand_: I don't see this problem, I think having a "set boot mode" endpoint is a problem
05:44:10 <devanand_> Iiuc, the proposals were to pass this on instance info
05:44:42 <devanand_> jroll: right. That's what I mean. A new REST endpoint fire this *is* a problem
05:44:51 <wanyen> jroll, there is not set_secure_boot_mode end point.  The set_secure_boot_mode mgmt i/f is for driver only
05:45:53 <jroll> wanyen: I understand
05:46:19 <wanyen> by the way, the passing capability flavor to ironic has been extended by Nova to 02/20.
05:46:40 <wanyen> we need to merge the code by 02/20.
05:47:00 <jroll> ok so to get this wrapped up: does anyone oppose merging set_secure_boot_mode into set_boot_mode?
05:47:20 <devanand_> wanyen: is nova waiting on us for anything?
05:47:39 <NobodyCam> i think it a good idea
05:47:40 <wanyen> I meant the ffe for passisng capability to ironic instance info has been classified as boderline and need to merge code by 02/20
05:48:04 <wanyen> code has been submitted and reviewed by several ironic core reviewers
05:48:13 <NobodyCam> should we # vote on it?
05:48:18 <wanyen> but we still need Nova reviewers to approve the code
05:48:36 <jroll> NobodyCam: I'd rather vote in the review
05:48:39 * jroll makes a review
05:48:48 <NobodyCam> ack
05:49:18 <NobodyCam> okay let jump on to: For partition image support in agent driver, submitted the common disk_partitioner code in oslo-incubator as "libironic"
05:49:24 <NobodyCam> faizan_: thats you
05:49:31 <naohirot> jroll: do you mean set_secure_boot_mode become third or fourth of paramter of set_boot_mode?
05:49:37 <NobodyCam> #link https://review.openstack.org/#/c/155190/
05:49:37 <jroll> should we #topic?
05:49:47 <jroll> naohirot: I mean make e.g. "uefi+secure" a boot mode
05:49:51 <jroll> that sets uefi and secure
05:49:51 <wanyen> jroll, I don't think we should merge set secure boot mode to set boot mode
05:49:55 <NobodyCam> oh I just set a agenda items topic
05:49:58 <jroll> ...........
05:50:06 <jroll> wanyen: please express that opinion on the reviw
05:50:09 <jroll> review, even
05:50:13 <NobodyCam> is faizan_ here?
05:50:18 <faizan_> jroll: devananda: I wanted to get clarity on where to host this piece of code
05:50:25 <wanyen> set-boot_mode has end poitn but set_ssecure_boot_mode doesn't
05:50:26 <NobodyCam> ahh
05:50:50 <jroll> ah, right.
05:50:53 <NobodyCam> wanyen: lets come back to that in Open Discussion
05:50:59 <jroll> so we talked about this some with jogo and others at the meetup
05:51:07 <wanyen> we only want it to be enabled via flavor not via a seperate mgmt endpoint.
05:51:09 <stendulker> Also we do not wat the secureboot API to be called except for during deploy
05:51:11 <jroll> we tend to think putting more things in oslo-incubator is bad
05:51:19 <jroll> stendulker: wanyen we've moved on
05:51:30 <NobodyCam> we have 9 minutes
05:51:50 <NobodyCam> lets move on and come back if theres time
05:51:52 <devanand_> #topic library for disk utils
05:52:05 <jroll> we talked about this some with jogo and others at the meetup
05:52:06 <faizan_> If everyone is of the opinion of not putting in oslo-incubator, then fine
05:52:12 <NobodyCam> #topic library for disk utils
05:52:13 <jroll> we tend to think putting more things in oslo-incubator is bad
05:52:19 <NobodyCam> @chair devanand_
05:52:22 <NobodyCam> gah
05:52:25 <devanand_> Hehe
05:52:26 <NobodyCam> #chair devanand_
05:52:27 <openstack> Current chairs: NobodyCam devanand_ devananda jroll
05:52:36 <jroll> I don't see any reason why we shouldn't just make this openstack/libironic, openstack/ironic-disk-utils, something like that
05:53:07 <devanand_> Where are these util consumed today?
05:53:18 <devanand_> Ironic, IPA, ...?
05:53:26 <jroll> this is about disk partitioning stuff, which is currently just ironic
05:53:29 <jroll> we want it in IPA
05:53:32 <NobodyCam> #link https://review.openstack.org/#/c/155190/
05:53:36 <faizan_> yes, only in these two places
05:53:38 <jroll> that *should* ne it
05:53:43 <jroll> be*
05:53:44 <devanand_> K
05:54:00 <jroll> I don't care about names, I care about keeping it out of oslo
05:54:06 <devanand_> Why?
05:54:26 <jroll> oslo incubator, mostly
05:54:35 <rameshg87> jroll, but apart from partitioning library, is there some other ironic functionality that can be shared between ironic and ipa ?
05:54:36 <jroll> because oslo incubator is weird
05:54:44 <jroll> rameshg87: it's unclear today, I think
05:54:55 <devanand_> jroll: why?
05:55:06 <rameshg87> jroll, if it's a library of one file for now, does it make sense to put it into a separate project of it's own
05:55:41 <jroll> devanand_: there's too much stuff there, updating sucks, etc
05:55:41 <faizan_> even though put it in oslo.incubator, eventually it will be merged in ironic/IPA under openstack/comm/libironc
05:56:10 <devanand_> Given the current simplicity of this, is the overhead worth it?
05:56:18 <jroll> devanand_: I hate the concept of oslo-incubator in general, also people are trying to keep it from bloating
05:56:27 <jroll> I *do* think it should be a library
05:56:45 <jroll> I tend not to care about where it lives, other than I'd like to keep it out of oslo-incubator
05:56:46 <JoshNang> metrics code could be shared between ironic and ipa
05:56:49 <devanand_> Whether Oslo incubator or a separate library project, are we gaining more than it will cost us to maintain?
05:57:01 <jroll> yes, partiioning is hard
05:57:22 <NobodyCam> maintaince is my concern
05:57:28 <NobodyCam> * 3 minutes
05:58:00 <devanand_> Oslo itself would seem a better place then
05:58:06 <jroll> we know how to maintain a library
05:58:15 <devanand_> Or we do our own library
05:58:40 <jroll> another reason for keeping it out of oslo-incubator, is that things in oslo-incubator are essentially marked as "unstable" and people are fine with breaking APIs
05:58:53 <devanand_> Well
05:59:09 <devanand_> In this case I think that's accurate
05:59:23 <NobodyCam> so our own lib?
05:59:42 <devanand_> Or rather guaranteeing q stable api for this, I don't see why that's something we need to do now
05:59:44 <jroll> what
05:59:48 <jroll> we already rely on the api
06:00:13 <NobodyCam> thats officially time
06:00:18 <devanand_> I'm missing something then
06:00:30 <NobodyCam> can we continue in channel?
06:00:37 <jroll> yes
06:00:38 <devanand_> Yep
06:00:48 <NobodyCam> Thank you all
06:01:07 <NobodyCam> let coninute in channel
06:01:13 <NobodyCam> @endmeeting
06:01:19 <NobodyCam> #endmeeting