17:00:04 <dtantsur> #startmeeting ironic
17:00:05 <openstack> Meeting started Mon May 22 17:00:04 2017 UTC and is due to finish in 60 minutes.  The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:08 <openstack> The meeting name has been set to 'ironic'
17:00:09 <jlvillal> o/
17:00:11 <rpioso> o/
17:00:12 <dtantsur> o/
17:00:12 <baha> o/
17:00:14 <stendulker> o/
17:00:17 <vdrok> o/
17:00:53 <dtantsur> hi everyone! welcome to the most ironic meeting in the openstack world :)
17:01:07 <anupn> o/
17:01:10 <jlvillal> :)
17:01:15 <crushil> \o
17:01:20 <dtantsur> our agenda can be found here:
17:01:23 <dtantsur> #link https://wiki.openstack.org/wiki/Meetings/Ironic
17:01:36 <xavierr> o/
17:01:46 <izumi777> o/
17:02:05 <dtantsur> #topic Announcements / Reminder
17:02:20 <dtantsur> #info dtantsur plans on the 1st IPA release for Pike
17:02:35 <dtantsur> we haven't done a release yet, so I'd prefer to do it this week
17:02:40 <sambetts> o/
17:03:01 <nicodemos> o/
17:03:14 <dtantsur> #info Pike-2 is in 2 weeks
17:03:19 <mjturek> o/
17:03:27 <dtantsur> which may not affect ironic itself too much, but is still something to keep in mind
17:03:43 <jlvillal> FYI: I will be attending a work event this week and then will be on vacation until 12-June-2017. Expect limited activity from me during this time :(
17:03:58 <dtantsur> thanks for the update, jlvillal
17:04:13 <dtantsur> #info jlvillal is mostly out till 12-June-2017
17:04:15 <sauloaislan> o/
17:04:29 <dtantsur> anyone has anything else?
17:05:12 <dtantsur> #topic Review subteam status reports (capped at ten minutes)
17:05:26 <dtantsur> #link https://etherpad.openstack.org/p/IronicWhiteBoard starting with line 94
17:06:10 <dtantsur> two BFV patches merged today, \o/
17:06:31 <jlvillal> Nice! Congrats TheJulia and everyone else.
17:06:42 * dtantsur wonders if TheJulia is around
17:06:54 <mjturek> \o/
17:07:02 <rajinir> o/
17:09:59 <dtantsur> folks, do you know some nova folks to chase to get https://review.openstack.org/#/c/419975/ reviewed?
17:11:23 <vdrok> hrm, I guess we can just ask someone in nova channel :)
17:11:58 <dtantsur> yeah.. anyone wants to do it or should I?
17:12:03 * dtantsur checks if we have the blueprint approved
17:12:42 <dtantsur> yeah, we do. so we can chase some folks
17:13:34 <dtantsur> #action dtantsur to try attracting some reviews to the nova patch for attach/detach https://review.openstack.org/#/c/419975/
17:15:37 <dtantsur> is everyone done reviewing the statuses?
17:16:16 <vdrok> I'm done :)
17:16:36 <dtantsur> #topic Deciding on priorities for the coming week
17:16:40 <dtantsur> we've done some good job!
17:17:00 <dtantsur> we managed to merge 2 install-guide updates and one of the BFV patches
17:17:12 <dtantsur> I'm certainly inclined to take the next BFV patch. wdyt?
17:17:55 <dtantsur> mjturek: do you plan on rebasing/updating https://review.openstack.org/#/c/406290 ?
17:18:11 <mjturek> dtantsur: I can handle it yep
17:18:33 <dtantsur> cool! I don't know if TheJulia plans on it, so please sync with her
17:18:34 <vdrok> dtantsur: I'm all for it, but I'd also love if the calls to storage interface were moved out of deploy :)
17:18:54 <mjturek> dtantsur: sure not sure if she's around but will ping her
17:18:56 <dtantsur> vdrok: well, this is something we can discuss on the patch :) where would you move them?
17:18:57 <vdrok> and into conductor
17:19:01 <dtantsur> ah
17:19:22 <dtantsur> yeah, let's discuss on the patch and/or on the BFV meeting on Thursday
17:19:27 <vdrok> I did comment on that, now it's time to advertise https://review.openstack.org/453139 :)
17:19:31 <vdrok> okie
17:19:46 <sambetts> I'm currently -1 on this and I've just left a comment on your RFE for that stuff
17:20:01 <vdrok> sambetts: thx, will  take a look
17:20:22 <dtantsur> sambetts, vdrok, I wonder if we need a spec that defines the policy of what goes in what interface, and what goes to the conductor
17:20:30 <dtantsur> there is a lot of misunderstanding here
17:20:43 <sambetts> dtantsur: https://bugs.launchpad.net/ironic/+bug/1679834
17:20:45 <openstack> Launchpad bug 1679834 in Ironic "[RFE] Moving network interface calls out of the deployment interface" [Wishlist,In progress] - Assigned to Vladyslav Drok (vdrok)
17:20:45 <dtantsur> I know some vendor folks are confused about boot-deploy separation, for example
17:20:52 <dtantsur> sambetts: yes, but a generic one.
17:21:00 <sambetts> +1 wondering if it needs converting
17:21:04 <dtantsur> vdrok: is it something you would like to write?
17:21:21 <vdrok> dtantsur: yeah, maybe s/spec/doc, dunno. it just does not seem right to me to have the separation and still call other interfaces from inside deploy
17:21:43 <vdrok> dtantsur: sure, will try to formulate something this week
17:21:47 <dtantsur> I think a spec would get more attention than docs
17:21:49 <dtantsur> thanks!
17:22:00 <dtantsur> back to the priorities. anything you would like to see there?
17:22:13 <dtantsur> and note that if you don't propose anything, I'll propose my install-guide changes :D
17:22:14 <vdrok> dtantsur: more of your docs patches? :D
17:22:23 <dtantsur> easy! :)
17:22:24 <vdrok> +=
17:23:51 <dtantsur> does the list look good now?
17:24:03 <sambetts> +1
17:24:08 * dtantsur wonders how many people are active on the meeting
17:24:12 <vdrok> fine with me
17:24:58 <dtantsur> okay, moving on
17:25:06 <dtantsur> #topic vendor additions to sushy: separate project(s) or submodule in sushy-tree?
17:25:13 <dtantsur> stendulker: your topic :)
17:25:24 <stendulker> Thanks
17:25:43 <stendulker> This is regarding how to enable the vendor redfish extensions
17:25:59 <deray> hi all.. I am in favour of submodule in Sushy-tree
17:26:11 <stendulker> In classic drivers all vendor code is part of their own libs
17:26:41 <vdrok> do you plan to have a CI for that?
17:26:44 <stendulker> The own libs provide flexibility to the vendors wrt things to add and release
17:27:30 <stendulker> We would add the CI for the Ironic redfish interfaces being supported
17:27:45 <dtantsur> I'd love to get more people to hack on sushy, and to make sure than vendor additions are consistent with it
17:27:54 <jlvillal> My default gut feeling is separate project. But my opinion could be changed :)
17:27:55 <stendulker> just as we do for the classic drivers
17:28:03 <dtantsur> stendulker: how much code and future changes do you expect for such vendor code?
17:28:36 <stendulker> In case of HPE, all the proliantutils code related to boot mode and inspection would be their into redfish
17:28:54 <stendulker> Also all the newer hardware features would get enabled only through redfish
17:28:56 <dtantsur> stendulker: boot mode - you mean configuring UEFI, right?
17:29:00 <wanyen_> I think vendor oem extension should be outside of Ironic and treat it like vnedor proliant util project for example
17:29:09 <stendulker> both UEI and UEFI secure boot
17:29:18 <vdrok> stendulker: so the way eg to get the boot device is different? just not sure what is vendor extension in this case
17:29:29 <dtantsur> vdrok: no, it's about UEFI (boot mode, not boot device)
17:29:37 <vdrok> oh, right
17:29:46 <dtantsur> I hope that power on/off and getting/setting boot device is more or less the same :)
17:29:56 <stendulker> Even in UEFI, there are extensions wrt UEFI target boot devices
17:30:00 * dtantsur is afraid to be proved wrong though
17:30:19 <deray> dtantsur, you r right
17:30:29 <stendulker> these things would vary from vendor to vendor and can be difficult to manage through single lib
17:31:00 <dtantsur> so, I see that folks tend to prefer separate libraries, right?
17:31:02 <wanyen_> vendor oem extension defines vendor specific features, such as oob RAID config, extended BIOS schema, etc
17:31:03 <stendulker> better to start as separate vendor libs and later on if required can get into sushy ....
17:31:14 <dtantsur> so e.g. with have sushy, then we have sushy-hpe, sushy-dell, etc?
17:31:26 <dtantsur> stendulker++ this is a very valid point
17:31:33 <rpioso> Please elaborate on the analogy with classic drivers.
17:31:55 <stendulker> In case of classic drivers all vendors have their own libs
17:32:10 <stendulker> like proliantutils for iLO , drc-client for drac and so on
17:32:44 <rpioso> stendulker: For DRAC, it's because WS-Man is used to communicate with the iDRAC BMC.
17:33:06 <rpioso> stendulker: That's the vendor unique aspect.
17:33:39 <wanyen_> also, vendor OEM extension can be very huge
17:33:44 <stendulker> yes, extensions are going to equally different implementations
17:33:44 <rpioso> stendulker: Won't Redfish be used, even for vendor exteensions.
17:34:31 <stendulker> it would be redfish, but how data is hosted for a similar resource would differ from vendor to vendor
17:35:07 <deray> rpioso, r u hinting that the Redfish mode of communication would remain the same and that makes it a possible candidate of reuse?
17:35:08 * sambetts isn't a fan of havn't them as "vendor specific" repo's because people see them as owned by the vendor and it puts of contributors that aren't the vendor but happen to have that vendors hardware
17:35:23 <sambetts> s/havn't/having
17:35:48 <stendulker> and most of these extensions exists because there is contention with regards to standardisation amongst vendors
17:36:08 <rpioso> deray: I'm just trying to identify the analogy.
17:36:08 <vdrok> so you're talking to extensions to sushy, not like vendor interface. as vendor interface should not be huge, and can be even in ironic tree if there is CI
17:36:18 <wanyen_> RedFish has standard schema and vendor OEM schema.  Vedor OEM extension is typically related to vendor specific hardware features and enhancements
17:36:41 <stendulker> sambetts: that is true to some extent, but these libs are also open sourced and uses only publicly documented interfaces
17:36:49 <vdrok> yup, I suppose it's better to keep it separate then
17:36:52 <deray> rpioso, okay
17:37:25 <rpioso> wanyen_: Could you provide an example or two?
17:37:36 <sambetts> stendulker: doesn't matter, if its called susy-hpe, I guarentee noone ecept hpe people will end up contibuting because people see it as owned by hpe
17:38:24 <wanyen_> smabetts, it's about who to review vendor specifc code
17:38:51 * rpioso notes that not every classic driver supports all ironic driver interfaces.
17:39:06 <vdrok> rpioso: I have an example of an ipmi extension -- https://github.com/openstack/ironic-staging-drivers/tree/master/ironic_staging_drivers/intel_nm, with redfish I suppose it's something similar, but doing http requests instead of calling a binary
17:39:35 <vdrok> these policies are not in standard ipmi afaik
17:39:58 <stendulker> sambetts: tht is true, but bigger factor is only ppl who have these vendor h/w can work on these libs. And such h/w is not common with all developers
17:40:20 <wanyen_> examples are if vendor BIOS support iscsi boot and it has oem extension to configure oob iscsi boot, same for storage raid controller, some vendor hardware supports oob RAID config, so it has oem ext to configure raid, etc
17:40:32 <dtantsur> which objections do we have except for potentially low contributor rate?
17:40:54 <dtantsur> we will need to define some stable SDK in sushy in this case for writing such vendor additions, obviously
17:41:28 <sambetts> dtantsur: I assume they won;t live inside Ironic's ownership if they are separate?
17:41:38 <sambetts> but susey will
17:41:51 <dtantsur> sambetts: this is correct (similar to how proliantutils and dracclient are treated nowadays)
17:42:05 <sambetts> which will make so IRC questions hard if we can't tell where susey stops and vendor thing ends
17:42:19 <sambetts> vendor thing begins*(
17:42:58 <vdrok> also iirc sushy was created as a very basic lib while redfishclient has issues, but i don't know the state of redfish client
17:43:02 <deray> sambetts, I guess we can add those OEM extensions to sushy as and when they become standards in Redfish
17:43:02 <stendulker> other option is to have the vendor libs importig sushy and having own names like hpe-redfish, dell-redfish etc
17:43:32 <rpioso> wanyem_: hrm, isn't oob RAID covered by the ironic classic driver RAID interface?
17:43:49 <sambetts> and we need to ensure that there is discoverablity for the vendor extensions too, because otherwise you run into the living breathing problem that is neutron drivers, and that no body knows they exist, what they support or how to install them
17:43:54 <stendulker> rpioso: no. RAID is in-band in classic drivers
17:43:55 <wanyen_> each vendor should name their ownlib
17:43:57 <rpioso> s/wanyem_/wanyen_/
17:44:40 <rpioso> stendulker: Not with the drac classic driver.  It's oob via the BMC.
17:44:40 <stendulker> rpioso: only DRAC has OOB raid I suppose
17:44:51 <stendulker> rpioso: yes.
17:45:20 <rpioso> stendulker: My point is that that's in the tree.
17:45:40 <sambetts> dtantsur: just from what I learned from conversations around drivers and in-tree vs out of tree and the neutron ml2 scenario, IMO out-of-tree makes everything worse
17:45:43 <rpioso> stenulker: The interface is common, while the underbelly is unique.
17:46:02 <wanyen_> fundamentally, each vendor has their own unique hardware or firmware features that's why vendor OEM ext is added to RedFish
17:46:04 <rpioso> s/stenulker/stendulker/
17:46:05 <stendulker> rpioso: but isnt it making call to drac-client?
17:46:52 <deray> dtantsur, > which objections do we have except for potentially low contributor rate? .. lot of duplicated code probably if not properly governed
17:47:07 <rpioso> stendulker: The implementation of that interface uses the drac-client.  It's at the bottom of the call stack.
17:47:12 <wanyen_> even more than one vendor has the same hardware features but their RedFish OEM extensions are different
17:47:12 <rpioso> deray: +1
17:47:20 <dtantsur> deray: this is very true. people may have to implement the same thing over and over
17:47:51 <dtantsur> even if the actual interface is different, the support code may be very close
17:48:19 <stendulker> rpioso: Common things we could add into the sushy and use it in vendor libs
17:48:19 <deray> dtantsur, rpioso but still there are many vendor extns which are kinda unique tho ..
17:48:27 <rpioso> rpioso: While it may be too soon to tell, I prefer we side on the assumption that more will be able to be reused, rather than less.
17:49:01 <dtantsur> deray: extensions, yes, but not necessary the code to implement them. it may different only e.g. in field names
17:49:03 <deray> stendulker, ++
17:49:28 <wanyen_> dtantsur, the redfish schema will be different and the link are different
17:49:44 <dtantsur> I know, this is not what I'm talking about
17:49:55 <dtantsur> there is a lot of code that *only* differs in field names
17:50:07 <deray> dtantsur, true to some extent.. I was actually talking bat features avaialable with different vendors
17:51:05 <rpioso> What's the plan for the other interfaces already supported by the classic driver?
17:51:23 <wanyen_> dtantsur, I think it will become very complicated if we try to generalize vendor oem extension. There is a reason why RedFish has Vendor OEM extension
17:51:29 <dtantsur> I'm also worried about things like high logging standard, and testing standard, etc (I'm not saying you folks don't have it, but it may start being quite different)
17:51:40 <dtantsur> wanyen_: this is also NOT what we're discussing here
17:51:44 <stendulker> rpioso:  no change. There is no redfish in classic drivers
17:52:02 <dtantsur> we're merely talking about code reuse, if the extensions will live e.g. in sushy.ext.<VENDOR>
17:52:05 <rpioso> stendulker: For example, RAID.
17:52:09 <stendulker> rpioso: there would be new interfaces based on redfish
17:52:28 <vdrok> so there are two options I suppose, put it in sushy or separately. I'd vote separately, as I will not be useful reviewing vendor extensions
17:52:42 <rpioso> Is out-of-tree a way to enable vendorts to add interfaces not yet implemented by ironic?
17:52:56 <dtantsur> rpioso: no
17:53:04 <vdrok> rpioso: vendor passthru :)
17:53:07 <wanyen_> vdrok, same here++
17:53:11 <dtantsur> well, yeah :)
17:53:46 <wanyen_> core members already have a lot of things to review
17:53:59 <dtantsur> ok, we seem to slightly more bias towards having them separate. stendulker, could you please post this discussion to the ML, so that people who are not here can voice their opinion too?
17:54:02 <rpioso> dtantsur: Does this have any relation to driver composition?
17:54:17 <sambetts> rpioso: nope
17:54:18 <stendulker> dtantsur: Sure
17:54:20 <wanyen_> so adding vendor specific code into sushy will make even more burden to reviewers
17:54:22 <dtantsur> rpioso: not direct. we're talking about implementations and where they live
17:54:42 <dtantsur> let's please move on. we have a preliminary result, let's reiterate on the ML over it.
17:54:55 <sambetts> 6 minute warning
17:54:57 <dtantsur> does it sound good?
17:55:01 <stendulker> dtantsur: thank you
17:55:04 <vdrok> rpioso: driver composition is about changing the way driver is composed from interfaces, not about changing the things that those interfaces do
17:55:07 <dtantsur> np, thanks for raising it
17:55:26 <dtantsur> we have one more topic to quickly go over
17:55:34 <dtantsur> #topic moving ironic-agent element to IPA
17:55:42 <dtantsur> #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/117170.html
17:55:45 <deray> I am in favour of having vendor plugin codes for sushy extns
17:56:03 <deray> probably out of tree from sushy
17:56:24 <vdrok> I'm +1 on a separate repo for all the build related stuff
17:56:29 <dtantsur> this was discussed on the summit, but just to reiterate. we want DIB as a supported means of building IPA, and that seems to require owning the element.
17:56:42 <dtantsur> sambetts proposed having a new repo, which folks seem to be in favour of
17:56:54 <dtantsur> any other opinions, questions or concerns?
17:57:11 <wanyen_> dtansur +1 for ironic to own its own DIB element
17:57:54 <wanyen_> Magnum took this approach
17:59:14 <dtantsur> ok, the last item will have to be moved out of meeting, but I'll raise it
17:59:18 <dtantsur> #topic RFE review
17:59:26 <dtantsur> #link https://bugs.launchpad.net/ironic-lib/+bug/1690458
17:59:28 <openstack> Launchpad bug 1690458 in ironic-lib "[RFE] During cleaning, remove also disk labels (not just partitions)" [Wishlist,Confirmed]
17:59:37 <dtantsur> please check it if you have time, and lemme know (or just comment on it)
17:59:46 <dtantsur> with this, thank you everyone!
18:00:02 <dtantsur> #endmeeting ironic