15:00:15 <TheJulia> #startmeeting ironic
15:00:16 <openstack> Meeting started Mon Jun 25 15:00:15 2018 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <TheJulia> o/ everyone!
15:00:20 <openstack> The meeting name has been set to 'ironic'
15:00:26 <dtantsur> o/
15:00:29 <TheJulia> Our agenda this week, as every week, is on the wiki!
15:00:32 <rpioso> o/
15:00:32 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic
15:00:37 <bdodd> o/
15:00:39 <etingof> o/
15:00:47 <TheJulia> #topic Announcements / Reminder
15:00:48 <rloo> o/
15:01:03 <hshiina> o/
15:01:04 <jiapei> o/
15:01:18 <hjensas> u/
15:01:48 <stendulker> o/
15:01:48 <mgoddard> o/
15:02:18 <TheJulia> This week is R-9. Typically we have to cut our final release around R-5 or R-4 in order not to be completely broken at the end of the cycle for a few weeks. So as a reminder, we have about a month of time left of time where we can merge things().
15:02:49 <cdearborn> \o
15:02:52 <TheJulia> I have no other announcements, other than I've got jetlag. ;)  Does anyone have anything they would like to annouce?
15:03:03 <TheJulia> announce ?
15:03:14 <rajinir> o/
15:03:18 <dtantsur> I've requested quite a few releases
15:03:23 <TheJulia> Ahh, yes!
15:03:33 <dtantsur> the master ones are done already, with ironic pike and ocata pending
15:03:44 <dtantsur> the ironic master release is awaiting the drivers removal I guess?
15:04:19 <openstackgerrit> Merged openstack/networking-generic-switch master: support hpe device type for the HPE 5900 series switches  https://review.openstack.org/471051
15:04:21 <TheJulia> dtantsur: I'd like to wait until we have them removed, since we're after the middle of the cycle
15:04:38 <dtantsur> yeah
15:04:48 * dtantsur urgently fixes bifrost, yay
15:04:55 <rpioso> dtantsur: How about sushy?
15:05:05 <dtantsur> rpioso: sushy master released
15:05:14 <dtantsur> 1.5.0, will hit upper-constraints soon(ish)
15:05:16 <TheJulia> dtantsur:  :(
15:05:27 <rpioso> dtantsur: \o/
15:05:41 <TheJulia> I guess we're ready to move on then
15:06:15 <TheJulia> #topic Review action items from previous meeting
15:06:40 <openstackgerrit> Merged openstack/sushy stable/pike: Change BootSourceOverrideMode from BIOS to Legacy  https://review.openstack.org/577582
15:07:04 <TheJulia> #info We had no action items last week \o/
15:07:32 <TheJulia> #topic Review subteam status reports
15:07:47 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:07:51 <TheJulia> Starting around line 156
15:09:37 <TheJulia> ohh, neutron event processing spec
15:10:03 <rloo> yay, graphical console spec was approved!
15:10:09 <TheJulia> yup
15:10:18 <rloo> wrt L203, dtantsur asks a question -- did we answer it?
15:11:16 <TheJulia> rloo: I've been slammed, I'll try to answer that and more this week
15:11:30 <rloo> TheJulia: no worries, is that an action item? :)
15:11:43 <TheJulia> #action TheJulia will try and condense operator feedback/asks from summit and OpenInfra Days Beijing in a written form this week.
15:12:01 <openstackgerrit> Dmitry Tantsur proposed openstack/bifrost master: Remove support for classic drivers  https://review.openstack.org/577848
15:12:05 <dtantsur> TheJulia: this looks like sad panda ^^^ but apparently needed...
15:12:08 <rloo> dtantsur: wrt the classic driver removal. the list there -- is that it or does it continue to grow? (L249 etc)
15:12:18 <TheJulia> Speaking of which, there are some surprisingly large ironic deployments in china
15:12:25 <TheJulia> dtantsur: c'est la vie
15:12:28 <dtantsur> rloo: it grows until the last enemy falls victim of my code removal skills
15:12:47 <rloo> dtantsur: heh. so we don't know how close we are to finishing that :-(
15:12:54 <TheJulia> dtantsur: I put the three you had up earlier this morning on the priorities to review this week, we should add the others I think
15:13:17 <rloo> wonder if we should push out a master release regardless of whether we remove them all or not.
15:13:43 <TheJulia> yolanda: You have an outstanding question on cleanhold it looks like. I'll try and answer that today
15:13:43 <rloo> not that i care that much, but the original intent was to release often, which means there is no way big features would be done w/i a release
15:13:48 <dtantsur> rloo: updated. it's not a lot of work in reality, just some consistent reviews (and rechecks)
15:14:07 <rloo> dtantsur: ok, i thought last week there was only one patch left so didn't keep an eye out.
15:14:16 <yolanda> hi TheJulia yes... may be because i don't get the whole workflow, but i was not understanding this part
15:15:00 <rloo> I'm deleting python 3.5 compat since it is being tracked in storyboard
15:15:09 <rloo> (L307)
15:15:44 <rloo> poof
15:15:45 <TheJulia> Re: actually writing down our vision. I think that can wait until we've cut our stable branch for this cycle.
15:16:11 <TheJulia> That is a nice quiet time typically
15:16:18 * TheJulia laughs at the idea
15:16:36 <rloo> assuming someone has time to actually write that down. maybe we should have made a video at the ptg :D
15:16:53 <TheJulia> ++++++
15:17:04 <TheJulia> Maybe ideas for the next PTG
15:17:18 <TheJulia> Anyway, I'm good with the updates. Shall we move on?
15:17:32 <rloo> +movin'
15:18:23 <TheJulia> #topic Deciding on priorities for the coming week
15:18:35 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:18:38 <TheJulia> Starting on line 98
15:18:46 <rloo> hardware type cleaning should be priority #1 since it is delaying our release
15:19:23 <TheJulia> good point
15:19:27 <TheJulia> moving
15:19:54 <TheJulia> I think that is about it....
15:20:22 <TheJulia> I moved the ipa fix up
15:20:25 <TheJulia> for secure erase
15:20:27 <dtantsur> I'll try to finish the remaining patches tomorrow
15:20:45 <dtantsur> it's no longer as difficult as it used to be with fake drivers - real drivers are rarely used in unit tests
15:21:01 <TheJulia> I'll try and get that hammered out this week, the failures seem to be sporatic timeouts on the ci jobs since we download and build lots of things in those jobs that are not really cached :\
15:21:19 <TheJulia> dtantsur: Awesome, thanks
15:21:25 <rloo> thx TheJulia
15:21:35 <rloo> TheJulia: can I put down that you will be looking at the CI failures?
15:21:43 <dtantsur> I think we have ironic-lib broken for.. time..
15:21:54 <TheJulia> rloo: yes
15:22:09 <TheJulia> dtantsur: similar issues, we need to adjust all the timeouts on it I think. :\
15:22:16 <rloo> Thx TheJulia
15:22:27 <TheJulia> I started down that path but didn't get too far...
15:22:32 * TheJulia wonders if we have anything outstanding there
15:22:50 <dtantsur> ironic-lib jobs also build IPA from source
15:23:09 <TheJulia> hmm, some stuff mjturek would likely prefer to see landed
15:23:23 <TheJulia> #action TheJulia to look at ironic-lib and IPA build timeouts this week
15:23:32 <TheJulia> yeah.. :( \o/
15:23:58 <TheJulia> I think we're good to move on?
15:24:18 <rloo> + moving
15:25:03 <TheJulia> #topic Discussion
15:26:04 <TheJulia> As some of you may know, sekharvajjula has been working on proposing a pure l3 deployment method for nokia hardware using virtual media, where there is no DHCP.
15:26:28 <TheJulia> #link https://review.openstack.org/#/c/543936/13/specs/approved/L3-based-deployment.rst
15:26:28 <patchbot> patch 543936 - ironic-specs - Added new spec for L3 based Ironic deployment
15:26:32 <dtantsur> I like the idea, but left two comments there
15:26:48 <dtantsur> only one of them may be an issue (the generic 'properties')
15:27:31 <TheJulia> Because of a virtual media limitation for their hardware where only one device can be attached, his current idea is to enable support for cases where the networking information gets appended to the end of the vmedia iso
15:27:59 <dtantsur> I assume it's still a valid ISO, right?
15:28:05 <TheJulia> I'm not sure there is a better way short of rebuilding the ISO, and I don't think Ironic should do that
15:28:12 * dtantsur recalls that it was possible to attach data filesystem to audio CDs
15:28:32 <TheJulia> dtantsur: I believe so yes, the file map is allocated upfront and maps to the blocks on disk, so appended data at the end shouldn't matter
15:28:56 <dtantsur> yeah, as long as we don't end with invalid ISO (which won't work), it's fine
15:29:14 <dtantsur> I wonder if it can happen that a BMC will strip the added part (or rather not expose it to the OS)
15:29:32 <TheJulia> sekharvajjula: do you know if iso tools handle the appended data?
15:29:38 <TheJulia> or if OSes handle it properly?
15:29:59 <dtantsur> (including BMCs themselves)
15:30:20 <TheJulia> dtantsur: that is a good question, I think they should just present a block device as long as the image.
15:30:41 <sekharvajjula> We have been using dd to append the network config to the end of ISO and read it, when os boots up from /dev/sr0 (CD) device
15:30:47 <dtantsur> that's a reasonable expectation, but may be worth calling out in the spec explicitly
15:30:57 <dtantsur> aha, so it works. good.
15:31:29 <sekharvajjula> We have this method tested on HP and on our own hardware as well
15:31:45 <TheJulia> sekharvajjula: okay, in that case, if it works, and your aware that you'll have to add some more mechanics to handle that in some cases, I'm good with that then. I'm not aware of dtantsur's comments he mentioned at the beginning of the discussion.
15:31:59 <dtantsur> yeah, just posted them
15:32:00 <TheJulia> sekharvajjula: That is awesome news
15:32:18 <dtantsur> but they may be easy to resolve
15:32:23 <TheJulia> okay, sounds like we have consensus on my concern, so Im good.
15:32:36 <TheJulia> dtantsur: do you wish to discuss your concerns?
15:32:45 <dtantsur> I can voice them
15:33:05 <dtantsur> 1. a free form port.properties. NOPE. please nope. if we need a new field, let's just add a purposed field.
15:33:33 <openstackgerrit> Merged openstack/networking-baremetal master: Remove the duplicated "the"  https://review.openstack.org/576317
15:33:33 <dtantsur> 2. I did not get the bit about virtmedia boot interfaces. are the existing (ilo-virtual-media, etc) fine or do we need yet another set?
15:33:34 <openstackgerrit> Merged openstack/networking-baremetal master: Switch to using stestr  https://review.openstack.org/574723
15:33:41 <dtantsur> if the latter, I need to understand why
15:34:00 <TheJulia> dtantsur: why? We have portgroup.properties?
15:34:08 <dtantsur> and node.properties. and it's ugly
15:34:09 <TheJulia> which too is just a json field
15:34:26 <dtantsur> well, we cannot fix the mistakes of the past so easily :) but we can avoid making new
15:34:34 <rloo> wrt 1. I agree with dtantsur, we have to start using fields instead of stuffing things in .properties.
15:34:49 <dtantsur> let me ask it this way: why do we need a field that is not versioned and is not introspectable?
15:34:55 <TheJulia> Okay, I'm convinced
15:35:00 <rloo> we've been meaning to clean up properties (eg capabilities) for a long time...
15:35:06 <TheJulia> yeah
15:35:29 <TheJulia> I just don't want to see us using extra, although people have been using extra fields for a while for misc things.
15:35:42 <dtantsur> note, I'm fine if the new field is also a JSON field, I just don't want it generic
15:35:52 <rloo> nope, not extra. we cannot/should not code anything that relies on anything from .extra
15:36:04 <TheJulia> rloo: agreed
15:36:06 <dtantsur> i.e. I want it to have a schema. and since we're in the microversion business, it should ideally be microversioned
15:37:00 <TheJulia> the fields existence, or the field contents, because content revision control seems overly restricting and hampering adaptation and improvement.... given our microversioning
15:37:05 <rloo> we've been using schemas for other things, so that makes sense. Have we used microversions? I don't recall any schemas changing.
15:37:32 <dtantsur> TheJulia: that's exactly what microversions are for ;)
15:37:41 <openstackgerrit> Ilya Etingof proposed openstack/virtualbmc master: Add reno noting recent changes  https://review.openstack.org/577851
15:37:45 <TheJulia> dtantsur: up for rewriting how we handle microversioning then?
15:37:59 <dtantsur> so yes, the field contents. and don't shoot the messenger - I'm not the one who proposed them :)
15:38:18 <TheJulia> so we can land more microversion impacting changes without needing new livers.
15:38:28 <dtantsur> TheJulia: why rewrite? in this case we just have different versions of JSON schema, similar to how Nova does it
15:38:46 <dtantsur> I don't propose to retrospectively start versioning other JSON fields (I propose killing them eventually)
15:39:02 <dtantsur> but this new is going to have a specific schema (based on os-net-config IIRC)
15:39:03 <rloo> before i forget, and i just skimmed the spec so don't grok it all, is there any security issue in appending that 'vfat image' to the boot iso? (can we validate the vfat image?)
15:39:07 <TheJulia> dtantsur: I mean all of the way that we structure the microversion code, means every change merge conflicts and has to be stacked. We've managed to stack some in advance, but yeah...
15:39:28 <dtantsur> TheJulia: I don't disagree with that, but it's a generic objection against microversions
15:39:58 <dtantsur> it's one of the reasons I proposed using "features" (like, strings) instead long ago (it was shot down instantly)
15:40:34 <TheJulia> I'm for it, but as our API is currently coded and maintained, I'm worried that we will hamper our ability further without some improvements. I almost feel like maybe we're inching towards a PTG topic of making API stuffs easier to land in the ironic code bsae
15:41:25 <dtantsur> ++ (modulo /me not going to the PTG)
15:41:32 <TheJulia> Lets decouple this discussion. Add a new field, and at the same time try and figure out how to achieve improved API versioning and schema control on that new field
15:41:57 <dtantsur> yeah, we can add it without thinking this through as long as it has a fixed schema
15:42:04 <rloo> I'm good with that
15:42:10 <sekharvajjula> so shall i update the spec with a new feild l3_network_configuration in both port and port_group?
15:42:10 <TheJulia> sounds good to me
15:42:26 * TheJulia is good with the name
15:42:47 <dtantsur> yep. and then the last question will be: what to do if this field is set to something for a boot interface that does not support it?
15:42:52 <dtantsur> i.e. the PXE boot?
15:43:07 <dtantsur> fail validation?
15:43:19 <TheJulia> dtantsur: yeah, we kind of went down the same road with
15:43:21 <TheJulia> with bfv
15:43:30 <dtantsur> right, it's similar
15:43:39 <TheJulia> and I think that is fine, which will kill the deployment early on
15:43:52 <TheJulia> that being if scheduling/config mismatches.
15:43:57 <dtantsur> okay, so fail validation?
15:44:02 <TheJulia> Yeah
15:44:26 <dtantsur> cool. sekharvajjula please reflect ^^^ in the spec
15:44:27 <TheJulia> boot interface validation, that leaves the remaining question of interface naming, and can this be wrapped in or not
15:44:40 <TheJulia> If we do the fail validation, I think we can use existing vmedia interfaces tbh
15:45:07 <sekharvajjula> dtantsur: good. I will update spec accordingly.
15:45:20 <dtantsur> I hope we do. I don't feel like we should multiply the interfaces without the vendor actually supporting several technologies
15:45:58 <TheJulia> Agreed, if adding "distinct" to that statement :)
15:46:10 <dtantsur> yeah :)
15:46:20 <TheJulia> Okay! Awesome
15:46:25 <TheJulia> sekharvajjula: thanks!
15:46:32 <TheJulia> Time to move on to open discussion!
15:46:40 <jiapei> Yean
15:46:44 <rloo> i had a security-related question ^^
15:46:45 <TheJulia> #topic Open Discussion
15:46:51 <sekharvajjula> still didn't get answer for dtantsur: 2nd question
15:46:53 <TheJulia> #undo
15:46:54 <openstack> Removing item from minutes: #topic Open Discussion
15:46:55 <TheJulia> rloo: yes?
15:47:07 <jiapei> yeah, I just want to confirm the CI setup schedule
15:47:19 <rloo> before i forget, and i just skimmed the spec so don't grok it all, is there any security issue in appending that 'vfat image' to the boot iso? (can we validate the vfat image?)
15:47:31 <TheJulia> jiapei: I looked at the email, hold on and let me compare to the rocky cycle schedule
15:48:07 <jiapei> TheJulia: Sure
15:48:20 <hjensas> sekharvajjula: Not to sure about l3_network_configuration is the best name? to me it's host_net_config? (bonds l2, ifconfig l3 ?) (it's a nit anyway ...)
15:48:25 <rloo> (I didn't grok yet where the info comes from for generating that vfat image)
15:48:26 <TheJulia> jiapei: It looks like your schedule was based on the rocky release schedule, however ironic releases earlier than that because of stable branch handling
15:48:38 <etingof> rloo, what can be a threat in case of a malformed vfat?
15:48:51 <rloo> etingof: i don't know. i'm not a security person.
15:49:14 <rloo> etingof: but ipa is going to do something with that. just want to make sure the info is from a trusted source or whatever.
15:49:29 <TheJulia> rloo: I believe the conductor in the case of this usage would create the data and apend it, while offering up the vmedia image to the BMC
15:49:40 <rloo> etingof: or maybe we don't have to worry about it.just asking.
15:49:59 <jiapei> TheJulia: well, so is there a last time for the CI? Currently we encounter some problems when setting up, still debuging it
15:50:12 <etingof> rloo, I am just trying to understand how that could be exploited
15:50:35 <jiapei> I mean when should the CI ready for the Ironic release
15:50:38 <etingof> rloo, is appended vfat anyhow different from just iso from the security standpoint?
15:50:39 <TheJulia> rloo: It would appear as local block device data, so I'm not entirely sure there is an issue there as long as however the file is shared is read-only (which should always be the case if a CD device is being emulated)
15:51:12 <dtantsur> jiapei: if you mean the xclarity CI, it was supposed to be ready by queens final..
15:51:33 <jiapei> Ah...
15:52:12 <sekharvajjula> TheJulia: +2
15:52:20 <rloo> and if we had had that CI working, we would have known that there were issues with the xclarity driver in queens. (Or else we would have found/fixed those issues) :-(
15:52:43 <rloo> ok, so no one thinks there is a security issue. we can move on then :)
15:53:35 <openstackgerrit> Merged openstack/sushy master: Introduce BIOS API  https://review.openstack.org/570555
15:54:28 <jiapei> :) Yeah, some issues can only be tested by the CI hardware, and we have tested it
15:54:53 <jiapei> We're building puppet and configure it this week
15:55:58 <openstackgerrit> Ilya Etingof proposed openstack/virtualbmc master: Add CI job to publish docs  https://review.openstack.org/577853
15:56:02 <TheJulia> jiapei: What dtantsur said. We've seen some progress. But... yeah, it needs to appear soon.
15:56:09 <TheJulia> Four minutes left
15:56:21 <TheJulia> #topic Open Disucssion
15:56:29 <TheJulia> #undo
15:56:29 <openstack> Removing item from minutes: #topic Open Disucssion
15:56:33 <TheJulia> #topic Open Discussion
15:56:39 <TheJulia> Anyone have anything else to discuss today?
15:57:05 <jiapei> TheJulia: We'll try our best to make it ready as soon as possible
15:57:50 <openstackgerrit> Ilya Etingof proposed openstack/virtualbmc master: Add reno for release notes management  https://review.openstack.org/577795
15:58:46 <TheJulia> jiapei: Thanks!
15:58:47 <rloo> crickets
15:58:52 <TheJulia> Thanks everyone!
15:58:59 <dtantsur> thanks
15:59:05 <TheJulia> #endmeeting