05:00:26 <devananda> #startmeeting ironic
05:00:27 <openstack> Meeting started Tue Jan 20 05:00:26 2015 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:00:30 <openstack> The meeting name has been set to 'ironic'
05:00:32 <devananda> hi folks!
05:00:36 <mrda> o/
05:00:38 <Nisha> hi devananda
05:00:42 <naohirot> o/
05:00:47 <takadayuiko> o/
05:00:49 <jroll> \o
05:01:09 <JayF> o/
05:01:10 <devananda> as usual, the agenda is on the wiki -
05:01:12 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
05:01:15 <vdrok_> o/
05:01:43 <devananda> today's a holiday inthe US. extra thanks to those who are here anyway :)
05:01:52 <devananda> #topic announcements
05:01:59 <mrda> what holiday?
05:02:09 <devananda> no special announcements from me -- other than a reminder that the midcycle sprints are coming up
05:02:18 <devananda> (yes, there are two -- one in the EU and one in the US)
05:02:19 <mrda> ahh, MLK
05:02:22 <devananda> mrda: yup
05:02:51 <devananda> if you plan on attending a sprint and have not already "purchased" a ticket through eventbrite, please do so
05:02:59 <devananda> that helps the organizing folks know how many are coming
05:03:13 <devananda> that's it for me -- anyone else have announcements?
05:03:28 <jroll> #link https://wiki.openstack.org/wiki/Sprints/IronicKiloSprint
05:03:39 <devananda> ah, thanks jroll
05:03:59 <devananda> #topic subteam status reports
05:04:05 <devananda> #link https://etherpad.openstack.org/p/IronicWhiteBoard
05:04:19 <wanyen> deva so the midcycle meeting at Grenoble is already a coding sprint? Will it discuss kilo2 target specs?
05:04:42 <wanyen> s/already/aslo
05:04:50 <wanyen> s/aslo/also
05:05:26 <devananda> wanyen: because many folks can't make it to one or the other (or either) event, I don't think we have a critical mass to do significant planning work
05:05:31 <devananda> wanyen: and we should continue doing that online
05:05:44 <wanyen> deva; ok
05:05:49 <devananda> wanyen: so I'd rather the folks who attend help each other focus on *implementing* the mountain of work we have
05:06:05 <devananda> ok - back to subteam status ...
05:06:24 <devananda> dtantsur led a bug-triage day last week
05:06:33 <devananda> it looks like it went really well!
05:07:04 <devananda> I see that we have an agenda item to discuss the iRMC driver, so let's not go into that here
05:07:12 <devananda> naohirot: thanks for the update on the etherpad, too
05:07:27 <naohirot> devananda: you are welcome.
05:07:47 <devananda> it looks like the iLO driver still has many specs that need reviews ...
05:08:04 <naohirot> devananda: kilo-2 is comming, will be iRMC management driver a part of it as well as power driver?
05:08:17 <wanyen> deva, yes ples review ilo specs
05:08:21 <devananda> #info bug triage day last week went well. should repeat it periodically
05:08:29 <devananda> #info iLO driver has many specs up that still need reviews
05:08:47 <devananda> naohirot: I hope so ... we'll see what folks are able to review
05:09:18 <rameshg87> here is status of ilo third-party ci
05:09:20 <naohirot> devananda and all: I'm ready to update as soon as I got comments :)
05:09:23 <rameshg87> we are in the process of setting up third party ci
05:09:27 <rameshg87> looking to add tests for iscsi_ilo and agent_ilo in gate and check pipelines
05:09:30 <rameshg87> planning some changes in devstack (lib/ironic) and devstack-gate (devstack-vm-gate-wrap.sh) for this.
05:09:34 <rameshg87> will raise gerrit reviews and pick ironic folks to have a look at this first.
05:09:42 <rameshg87> s/pick/ping :)
05:09:48 <devananda> rameshg87: awesome!
05:10:50 <devananda> rameshg87: please don't hesitate to ask questions about setting up the CI system. I work with (and very briefly worked on) the infra team
05:11:07 <devananda> at the least, I can point you to docs or the people who know more
05:11:11 <rameshg87> devananda, i follow a blog written by Jay Pipes
05:11:31 <devananda> rameshg87: if that's the one I'm thinking of, it's a good walk through :)
05:11:33 <rameshg87> devananda, it's explained in detail except that lots of things in openstack-infra has changed since tutorial was written
05:11:38 <devananda> yep
05:11:48 <rameshg87> devananda, just need to figure out where things are right now :)
05:11:59 <devananda> anteaya may be able to help there
05:12:00 <mrda> there's also some infra people in this TZ that can help if required.
05:12:07 <mrda> jhesketh for example
05:12:14 <jaypipes> rameshg87: you should use the fork of the os-ext-testing repository from ramy asselin:
05:12:18 <rameshg87> devananda, mrda, thanks ..
05:12:30 <rameshg87> jaypipes, great ..
05:12:48 <rameshg87> jaypipes, thanks. i was making changes to that and was planning to raise a pull request to you :)
05:12:51 <mrda> and maybe jaypipes is in *every* timezone :)
05:13:23 <devananda> lol
05:14:13 <devananda> ok - going to time box this section
05:14:22 <devananda> thanks again, everyone, for the status updates
05:14:36 <devananda> #topic driver naming conventions
05:14:54 <devananda> naohirot: I think you stumbled into a much larger question accidentally here
05:15:27 <devananda> and by "larger" I actually mean "it's a giant bikeshed"
05:15:28 <naohirot> devananda: yes, should I explain background?
05:15:52 <devananda> naohirot: sure
05:16:34 <naohirot> devananda: I got a comment from JayF during the reivew of iRMC Management spec.
05:16:49 <naohirot> https://review.openstack.org/#/c/136020/10/specs/kilo/irmc-management-driver.rst
05:17:18 <naohirot> please look at the line 30
05:18:01 <devananda> JayF and jroll and I had started discussing it just before the meeting
05:18:03 <naohirot> devananda: I saw devananda and jroll's conversation in the Ironic channnel
05:18:10 <devananda> :)
05:18:44 <devananda> short version from my POV - as we add more driver interfaces, the names of drivers either:
05:18:44 <naohirot> it seems it's famous boot and deploy problem.
05:18:55 <wanyen> chaning driver name involves backward compatibility
05:19:12 <devananda> - become longer and more descriptive and tend towards a list of interface classes from which that driver is composed
05:19:21 <devananda> - or shorter and "cute"
05:19:52 <jroll> I've said it since the summit, I think we need composable drivers
05:19:58 <jroll> as in a column for each type
05:20:06 <naohirot> what I'd like to discuss here is how to approach this problem.
05:20:16 <devananda> but either way we go, changing current driver names would require us to keep the existing pythong enrypoints for compatibility
05:20:23 <rameshg87> jroll, do you mean operator picks up the interfaces for the composable driver ?
05:20:45 <jroll> rameshg87: I'm not entirely sure it will work, ideally the operator just puts driver names in the db and it just works
05:20:51 <jroll> anyway, that's beyond this discussion.
05:21:12 <JayF> I think a longer, more descriptive name is better. We already have enough trouble about 'what's the difference between drivers' without bringing cutesy names into it.
05:21:14 <jroll> I tend to think it's fine to go outside of the current "convention" that isn't really defined
05:21:15 <naohirot> I'd prefer the first option, issuing a bp and redactor
05:21:37 <devananda> jroll: I disagree for two reasons. first (and possibly solvable) is that this leads to a combinatorial explosion of testing requirements. second (and human in nature) is that operators are probably going to pick a reasonably small subset of the potential combinations
05:21:42 <devananda> so we should just give them those choices
05:21:51 <jroll> for irmc, name them similar to what JayF suggested. leave the rest alone for now
05:22:01 <devananda> like - who would compose ipmi-power and ilo-boot
05:22:06 <jroll> devananda: maybe it's just me being a nerd
05:22:13 <devananda> when ilo implements both power and boot
05:22:20 <rameshg87> this doesn't happen for all drivers. should we just break the convention whenever it is required only ?
05:22:33 <devananda> that's a trivial example which we would immediately hit, were we to allow arbitrary compositing
05:22:43 <jroll> yeah, I think it's fine to break convention
05:22:43 <JayF> devananda: I generally see the matrix as being pxe vs some kind of BMC boot * the two "major" deploy drivers
05:23:04 <JayF> devananda: that matrix of 4 drivers per new virtualmedia-capable management driver is going to be common
05:23:08 <devananda> JayF: that statement assumes there are no other deploy drivers
05:23:18 <devananda> JayF: and it assumes other interfaces are not being mixed in through other means
05:23:19 <JayF> and the only way to really fix that is to have fewer deploy drivers
05:23:26 <devananda> such as console or raid
05:23:26 <JayF> or start talking about drivers in ways other than static names
05:23:42 <JayF> exactly
05:23:46 <mrda> I think it's worth noting that OpenStack generally is quite opinionated
05:23:53 <devananda> mrda: yup
05:23:57 <devananda> I'm all for the opinion here
05:24:01 <mrda> lol
05:24:18 <devananda> and I wouldn't mind having cute names. we already give our projects names -- why not the drivers? :)
05:24:21 <JayF> I mean, lets look at the iRMC example again
05:24:34 <JayF> what "opinion" would we have? All 4 drivers would have merit in different use case.s
05:24:38 <mrda> (unless good reason not to follow suit)
05:24:49 <JayF> it's just another thing to bikeshed over
05:25:37 <devananda> today we effectively have: (power) + (boot) + (deploy) + (management) + (console)
05:26:08 <devananda> in some cases, many of these are provided by a single implementation, eg, ilo provides power, boot, management, and console
05:26:26 <devananda> so we get just (ilo) + (iscsi, agent)
05:26:39 <naohirot> devananda: I see, now I understood the real background of the driver naming
05:26:51 <devananda> I imagine that other vendor-specific drivers will tend towards a similar state
05:27:01 <devananda> (vendor) + (deploy method)
05:27:27 <naohirot> devananda: name consists of 5 words ideally.
05:27:48 <devananda> but what if I want to use the IPMI 2.0 standard SOL session instead of iLO's ?
05:28:02 <devananda> right now, I can't.
05:28:16 <devananda> that's an opinion. I think it's fine if Ironic has that sort of opinion.
05:28:28 <jroll> ++
05:29:27 <JayF> Sure. but that still doesn't help the issue at hand with iRMC. Should we say we only want to support a given kind of boot?
05:29:41 <wanyen> Not quite sure why a user wants to use ipmi and iLO deploy and boot combination
05:29:57 <jroll> I'm ok with just supporting virtualmedia, as long as all irmc hardware has VM support
05:30:37 <JayF> That means booting anything using iRMC driver requires CIFS/NFS
05:32:02 <jroll> oh, that's a thing
05:32:03 <jroll> I mean
05:32:05 <JayF> I just want us to get somewhere with the conversation; have a specific answer for naohirot so that spec doesn't stay in limbo, even if we have to continue thinking about overall naming and composability of drivers
05:32:16 <jroll> if we want to support all four; name them distinctly like JayF suggested
05:32:19 <JayF> I obviously think the best path for that is implement the 4 drivers, name them what I suggested :)
05:32:19 <mrda> +1
05:32:23 <devananda> JayF: ++
05:32:32 <devananda> er, I mean, +1 on getting to a specific answer
05:32:40 <devananda> I'm looking at the ilo* drivers right now -- there are three
05:32:42 <devananda> (not counting fake)
05:32:47 * JayF would rather not stay up to look at a non-moving IRC meeting
05:33:25 <devananda> JayF: of the four you're suggesting,a nd the three that ilo implements ,what's missing?
05:33:44 <wanyen> deva, ilo driver doesn nt use ipmi
05:33:44 <devananda> vm_iscsi?
05:33:48 <JayF> it's just a matrix, pxe/agent vs pxeboot/virtualmedia
05:33:57 <JayF> I think they may not have agent/virtualmedia yet
05:34:01 <devananda> wanyen: I know :) that was just an example to illustrate a point
05:34:02 <JayF> but imbw
05:34:21 <wanyen> that's why iLo driver only has 3 drivers not 4
05:34:33 <devananda> JayF: IloVirtualMediaAgentDriver
05:35:27 <JayF> devananda: agent + pxe is missing
05:35:48 <JayF> we do not have a driver that uses iLo management + pxe boots + IPA deploy
05:35:54 <rameshg87> JayF, yes, it's not there ..
05:35:57 <devananda> oh. right
05:36:06 <devananda> agent + pxe boot + ilo for power, mgmt
05:36:10 <JayF> see; I almost think that's a bug
05:36:19 <JayF> there's no reason that doesn't exist other than because it doesn't
05:36:28 <devananda> because there is iscsi + pxe boot + ilo for power, mgmt
05:36:30 <devananda> yea
05:36:56 <devananda> JayF: so this is where, apparently, the authors of that driver (or we as a community) had an opinion
05:37:00 <jroll> I mean, it's not a bug until someone wants it
05:37:02 <devananda> or we just skipped it
05:37:08 <devananda> because no one wanted it
05:37:21 <rameshg87> devananda, JayF, there was a reason for that have iscsi + pxe boot + ilo for power, mgmt. it helps to deal with uefi systems
05:37:25 <JayF> I was more suspecting it was an oversight
05:37:45 <devananda> in short, I don't think we should be telling the driver authors what combinations of interfaces they should be providing. they should listen to their users and implement that
05:37:46 <rameshg87> devananda, JayF, when agent supports uefi, we can as well have it
05:38:18 <JayF> devananda: that's reasonable; but I would still say the drivers should be named more descriptively, even if we don't want to implement the full matrix
05:38:29 <JayF> but I want that to be a decision; not an oversight
05:38:31 <jroll> or we should document the mapping
05:38:36 <wanyen> deva ++
05:38:48 <JayF> given it was modelled on what drivers iLo had before; I suspect it was not a decision explicitly mad
05:38:50 <JayF> *made
05:38:56 <devananda> JayF: fair points
05:39:08 <devananda> naohirot: what combinations of interfaces matter to you / /your users?
05:39:53 <naohirot> devananda: I just would like to follow the ilo implementation as the first step.
05:40:21 <devananda> rameshg87: are you saying that PXE boot is necessary for UEFI support (and works better than iLO vmedia boot for that) ?
05:40:28 <naohirot> devananda: so it's difficult to answer your question.:-)
05:40:47 <wanyen> deva, ipmi toll does not handle boot mode
05:40:51 <devananda> naohirot: are you planning to test all of them, or just one?
05:41:10 <rameshg87> devananda, setting boot device doesn't work well with ipmi. pxe boot + ilo mgmt  on uefi works
05:41:12 <wanyen> so we have pxe-ilo driver using ilo to manage boot mode
05:41:48 <devananda> rameshg87: ahh. gotcha. so for a user who wants to use PXE boot, they need to use iLO mgmt (rather than IPMI) to enable UEFI
05:41:51 <devananda> rameshg87: thanks
05:41:58 <rameshg87> devananda, yeah
05:42:07 <JayF> devananda: aiui, that's the same difference with iRMC as well
05:42:19 <JayF> devananda: at least that's what I gleaned from the spec
05:42:22 <naohirot> devananda: I think right now there is no concrete customer, my concern is to implement workable driver and ask potential customer's feedback.
05:43:01 <devananda> naohirot: my advice would then be, start with the simplest one that provides the functionality you think your customers want
05:43:07 <naohirot> devananda: that's the reason I'd like to implement the way ilo does right now.
05:43:09 <Haomeng|2> rameshg87: do you mean it does not support 'persistent' option?
05:43:16 <devananda> naohirot: rather than trying to support 3 separate drivers initially
05:43:34 <rameshg87> Haomeng|2, no. setting boot device itself doesn't work properly with ipmi. it's not related to persistent option.
05:43:34 <devananda> s/separate/different combinations of/
05:43:47 <rameshg87> Haomeng|2, i mean only on uefi machines
05:43:49 <devananda> rameshg87: you mean boot mode, not device, right?
05:43:56 <rameshg87> devananda, both infact :)
05:43:57 <Haomeng|2> rameshg87: ok
05:44:16 <naohirot> devananda: I'd rather shipping small set of driver rather than complete one.
05:44:20 <devananda> rameshg87: oh, hmmm. I haven't seen problems setting boot device like that. thanks
05:44:36 <JayF> naohirot: then as a suggestion, why not do the virtual media boot drivers later?
05:44:54 <JayF> naohirot: the pxe / agent deploy drivers, if pxe booting, should be very quick to get up and proof of concept
05:45:05 <rameshg87> devananda, for reference, we have code to handle that - https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L334-L348
05:45:13 <devananda> JayF: ++
05:45:15 <jroll> JayF: ++ just need power driver for that
05:45:17 <naohirot> JayF: That's what I'm doing.
05:45:31 <JayF> cool, then if we do that I'd be OK with pxe_irmc / agent_irmc drivers
05:45:35 <devananda> jroll: I think the power driver already got approved, no?
05:45:49 <naohirot> JayF: I implement PXE+iRMC without virtual media first.
05:45:53 <JayF> perfect
05:45:54 <jroll> devananda: maybe? idk if everything is wired up
05:46:15 <jroll> people can ignore me if I'm wrong :P
05:46:33 <naohirot> JayF: :)
05:46:43 <devananda> jroll:
05:46:44 <devananda> http://specs.openstack.org/openstack/ironic-specs/specs/kilo/irmc-power-driver.html
05:46:50 <devananda> oops
05:46:55 <devananda> bad paste, but right link
05:46:57 <jroll> devananda: cool, but is there code
05:47:16 <devananda> oh...
05:47:26 <jroll> it's irrelevant for this discussion though
05:47:28 <jroll> ignore me
05:48:16 <devananda> naohirot: does that work for you? just pxe_irmc and agent_irmc for now
05:48:34 <naohirot> devananda: yes
05:49:14 <devananda> #agreed iRMC work to proceed with two drivers (pxe_irmc and agent_irmc) and no vmedia support initially, but that may come later
05:49:26 <devananda> #topic open discussion
05:49:32 <naohirot> devananda: agent_irmc uses virtual media, but pxe_irmc doesn't use virtualmedia.
05:49:34 <lintan_> wanyen: Hi, do you have time to discuss with secure mode
05:49:50 <wanyen> lintan, sure
05:50:03 <devananda> naohirot: ah, gotcha. that's fine too
05:50:05 <vdrok_> I have a small question about deploy_key that i put to instance_info during deployment
05:50:08 <devananda> #undo
05:50:09 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2251190>
05:50:18 <vdrok_> do we really need it?
05:50:23 <lintan_> wanyen: first, do you think is it necessary to have one interface for secure boot or trust boot?
05:50:24 <devananda> #agreed correction - agent_irmc will use vmedia, and pxe_irmc will not
05:50:27 <devananda> #topic open discussion
05:50:39 <jroll> vdrok_: I'm not aware of this, isn't that something ironic puts in?
05:50:54 <jroll> vdrok_: (or it doesn't go there at all)
05:51:05 <wanyen> lintan, no I don't think so.  I thin make them seprate will be more clear
05:51:14 <vdrok_> jroll, yes, but it's checked only here - https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/iscsi_deploy.py#L220-L221
05:51:15 <wanyen> s/thin/think
05:51:20 <naohirot> devananda: Just make sure there is no misunderstainding. agent_irmc and iscsi_irmc use virtual media, pxe_irmc doesn't use virtual media.
05:51:31 <vdrok_> which is called on continue_deploy
05:51:52 <vdrok_> and it seems that it can't really change
05:51:52 <lintan_> wanyen: but they are very similar and work for the same goal
05:52:02 <jroll> vdrok_: right, that's a pxe driver thing, I'm not sure what it does though
05:52:12 <jroll> vdrok_: but I thought ironic puts it there automatically
05:52:43 <devananda> vdrok_: it is created here: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/iscsi_deploy.py#L336
05:52:45 <jroll> vdrok_: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/iscsi_deploy.py#L334-338
05:52:45 <wanyen> lintan, they protect bare-metal node at differnt phases and user may want to be sure what they will have
05:52:58 <devananda> vdrok_: and lives only temporarily -- just for the duration of that deploy ramdisk
05:53:03 <vdrok_> devananda, yes
05:53:14 <vdrok_> devananda, but do we need it actually?
05:53:24 <devananda> vdrok_: it is used as a very crude authentication method
05:53:32 <devananda> vdrok_: the deploy ramdisk POSTs it back
05:53:35 <devananda> and ironic validates it
05:53:48 <jroll> devananda: doesn't the keystone token cover auth?
05:53:50 <wanyen> lintan, for security feature I think it's importatn for user to know what they end up with, either trusted boot or secure boot
05:54:08 <devananda> gah. it's late. I mean authorization
05:54:27 <jroll> mmm
05:54:41 <devananda> jroll: you're correct - keystone token covers authentication. this token authorizes that deploy ramdisk to receive the instance image
05:54:49 <jroll> huh
05:54:57 <devananda> because, presumably, no other ramdisk received *taht* token on boot
05:54:59 <jroll> I guess that's useful
05:55:09 <devananda> even if other ramdisks received the same keystone token
05:55:34 <lintan_> wanyen, we can left the choice for user, but from perspective of Ironic, they are same
05:56:12 <lintan_> wanyen, similar I mean, they can share a interface
05:56:45 <devananda> it's not all that secure, but it's better than not having it. I would much rather inject some key material over the OOB (vmedia) channel ... but that's not possible with standard IPMI in any way I know of
05:57:09 <vdrok_> devananda, but it can change only if user will explicitly change it in instance_info?
05:57:15 <wanyen> lintan, I would like ot use r differnt flavors for trusted boot vs secure boot.
05:57:18 <devananda> vdrok_: it does not change
05:57:33 <vdrok_> oh, right, its internal
05:57:43 <wanyen> lintan, for managerinterface, we can discuss what would be best : eitehr to have two interfaces or one
05:57:43 <devananda> vdrok_: it is created by the PXE driver during deploy, then deleted when the deploy is done
05:57:47 <devananda> right
05:57:52 <lintan_> wanyen, different flavor is OK with me
05:58:24 <jroll> does trusted boot imply secure boot?
05:58:28 <jroll> (just curious)
05:58:35 <lintan_> wanyen, we still need to save extra spec in ironic db
05:58:35 <stendulker> lintan: falvor would be better choice as user would know what he wants
05:58:52 <lintan_> jroll: yes trusted boot are secure boot as well
05:58:59 <jroll> stendulker: (or she)
05:59:07 <stendulker> jroll: he :)
05:59:11 <jroll> ...
05:59:19 <wanyen> lintan, flavor will be passed as part of the instance_info ti ironic
05:59:28 <jroll> anyway, I think our time is up
05:59:39 <devananda> yep
05:59:40 <jroll> wanyen: ironic doesn't know about flavors
05:59:45 <rameshg87> i had one item for open discussion :(
05:59:51 <stendulker> jroll : Trusted and secure boot differ and they work bit differently but try to achieve the same goal of having uncompromised OS image
05:59:55 <rameshg87> i was waiting for these to complete
06:00:07 <devananda> rameshg87: we started open discussion 10 minutes ago ...
06:00:16 <jroll> stendulker: right
06:00:20 <wanyen> jroll, I meant flavor will be copied into instance_info/capabilities
06:00:24 <rameshg87> devananda, i was waiting to avoid chaos
06:00:34 <devananda> rameshg87: embrace the chaos :)
06:00:38 <jroll> heh
06:00:42 <devananda> rameshg87: or bring it up on the mailing list?
06:00:43 <naohirot> rameshg87: :)
06:00:44 <mrda> rameshg87: to the channel then :)
06:00:47 <devananda> also, we're out of time
06:00:50 <devananda> thanks everyone!
06:00:54 <mrda> thanks devananda!
06:00:59 <jroll> thanks folks :D
06:01:01 <devananda> #endmeeting