15:00:16 <TheJulia> #startmeeting ironic
15:00:16 <openstack> Meeting started Mon Apr  1 15:00:16 2019 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:20 <openstack> The meeting name has been set to 'ironic'
15:00:26 <TheJulia> Speaking of meetings! It is time for our weekly meeting!
15:00:28 <etingof> \o/
15:00:36 <TheJulia> Our agenda, as always, can be found on the wiki.
15:00:37 <dtantsur> \o
15:00:38 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:00:39 <iurygregory> o/
15:00:39 <rpittau> o/
15:00:42 <arne_wiebalck> o/
15:00:44 <bdodd> o/
15:00:50 <dnuka> o/
15:01:02 <TheJulia> This week, it looks fairly lightweight, Hopefully this will be a quick meeting and then we can go back to taking over the world.
15:01:08 <stendulker> o/
15:01:16 <TheJulia> #topic Announcements / Reminders
15:01:53 <TheJulia> #info The PTG topic etherpad is up for review. Please add any additional topics and discussion by Friday of this week.
15:02:06 <rpioso> o/
15:02:09 <kaifeng> o/
15:02:10 <jroll> \o
15:02:12 <rloo> o/
15:02:12 <TheJulia> #info Next week, we shall review the PTG topic etherpad and add +1s to it in order to help form the basis of an agenda.
15:02:19 <TheJulia> #link https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming
15:02:30 <TheJulia> Does anyone have anything else to add?
15:02:35 <dtantsur> oh, it's in 4 weeks. time flies indeed
15:02:49 <dtantsur> TheJulia: we should check if we need another round of stein releases, I guess?
15:03:13 <TheJulia> We should, although I think we have a couple minor patches still in review first
15:03:15 <cdearborn> o/
15:03:37 <TheJulia> We may also need to other stable branch releases as well
15:03:57 <TheJulia> dtantsur: Thursday I think seems like a good day to check on all of that.
15:04:04 <dtantsur> indeed
15:04:24 <dtantsur> other stable branches need sorting out the iDRAC pxe_enabled issue
15:04:29 <TheJulia> ++
15:04:48 <TheJulia> I talked to rpioso friday afternoon ?or was it evening? about it
15:05:23 <TheJulia> It seems like we have a forward path there, just waiting for new patches to get posted.
15:05:39 <rpioso> dtantsur, TheJulia: We're working on it.
15:05:47 <TheJulia> rpioso: Awesome, thanks!
15:06:28 <TheJulia> Well if there is no other reminders or announcements, We can skip forward to reviewing subteam status reports
15:06:35 <TheJulia> Since there were no action items last week.
15:07:39 * TheJulia hears crickets and proceeds forward
15:07:42 <TheJulia> #topic Review subteam status reports
15:07:50 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:08:09 <TheJulia> Starting at line 240
15:09:01 <TheJulia> Python3 wise, it seems largely out of date and seems to have creeped scope to include discussion about dropping 3.5 support
15:09:22 <TheJulia> I feel it is time to maybe transform that entry? thoughts?
15:09:40 <rloo> ++ transform
15:09:49 <dtantsur> yeah
15:09:52 <rpittau> sounds good
15:09:54 <iurygregory> ++
15:10:43 <TheJulia> Okay! Note added!
15:11:07 <rloo> TheJulia: do you or who knows the status of all those things listed under Python3 first?
15:11:19 * jroll strikes through his items on there
15:11:37 <rloo> thx jroll :)
15:11:38 <rpittau> rloo: everything shoule be good on Python 3
15:11:47 <rpittau> s/shoule/should
15:11:49 <TheJulia> rloo: I think we're done with python3 first except maybe bifrost, I dont' remember there. Zuul job wise which got wrapped up in all of that we still have some stuff to migrate
15:11:52 <TheJulia> but minimal at this point
15:11:53 <rloo> rpittau: please strike/delete stuff there that is out of date then.
15:12:23 <TheJulia> UEFI wise, we should continue to push forward there. We do need the CI job coverage at some point, hopefully I'll have time one year.
15:12:47 <rpittau> TheJulia: the one uefi job on bionic is working
15:12:52 <TheJulia> \o/
15:12:57 <rloo> TheJulia: and docs still needed for uefi?
15:13:00 <TheJulia> So beyond that it is just additional scenarios
15:13:15 <TheJulia> rloo: I believe we merged them
15:14:00 <TheJulia> yup, doc updates merged
15:14:27 <TheJulia> Struck through out of date items there
15:14:36 <rpittau> we should move zuulv3 migration from python3 first
15:14:47 <TheJulia> rpittau: Please
15:14:59 <rpittau> done :P
15:15:01 <TheJulia> Role splitting I think is a continuing topic
15:15:18 <TheJulia> Deploy templates, I believe mgoddard's current patches are all WIPs?
15:16:02 <TheJulia> arne_wiebalck: Ohh, nice idea w/r/t automatic cleaning :)
15:16:10 <TheJulia> Thank you for updating software raid :)
15:16:19 <arne_wiebalck> TheJulia: thx for the reviews
15:16:21 <TheJulia> Fast track, I need to find time to work on testing
15:16:35 <TheJulia> #action TheJulia to add links to fast track section
15:16:44 <TheJulia> Since you know... then I can actually say we had action items :)
15:16:59 * rloo loves action items
15:17:14 * arne_wiebalck loves action items on someone else
15:17:29 <TheJulia> From my reviewing this morning, etingof's virutal media patches are still in review
15:17:39 <TheJulia> And phase one of locking still requires reviews
15:18:01 <rloo> arne_wiebalck: wrt software RAID (L299). hasn't the spec landed?
15:18:09 <TheJulia> rloo: he revised the spec
15:18:25 <arne_wiebalck> rloo: the main one yes
15:18:25 <TheJulia> for additional clarity and minor behavior change from code review discussions
15:18:29 <rloo> arne_wiebalck: maybe add the link to the revision then.
15:18:36 <arne_wiebalck> rloo: ok!
15:19:32 <TheJulia> I suspect smartnics should be able to move again on the neutron side soon-ish. I'll inquire with the Neutron PTL.
15:20:01 <rloo> wrt locking (L318). are there links to any docs or story or ??
15:20:03 <TheJulia> #action TheJulia to follow-up with neutron folks regarding smartnic
15:21:13 <TheJulia> rloo: locking discussion has been a bit less formal and kind of a prerequisite of other items so we've been trying to hash it out on code reviews. There is a item we copied over that jroll created ages ago in storyboard... I'd have to look but I believe it is linked on the patch.
15:21:36 <TheJulia> hjensas: any update on Neutron event processing?
15:21:43 <rloo> TheJulia: thx
15:22:07 <TheJulia> Regarding HTTPClient booting, I've had a few people express interest in this area over the past week, so I think people may be interested in helping with this item.
15:22:08 <hjensas> TheJulia: I've put a hold on working that effort until after PTG.
15:22:16 <TheJulia> hjensas: ack
15:22:47 <TheJulia> The same along with the DHCP-less/L3 Vmedia boot
15:23:24 <TheJulia> I noticed some work has continued on graphical console support, so that entry is up to date.
15:24:04 <TheJulia> jroll: any word on conductor->ipa comm flow changes?
15:24:37 <jroll> TheJulia: no updates
15:24:52 <TheJulia> jroll: And you will not be at the summit/ptg?
15:24:54 <jroll> if anything, it's dropped lower on my priority list :(
15:24:58 <jroll> TheJulia: correct
15:25:02 <TheJulia> :(
15:25:03 <TheJulia> okay
15:25:09 <jroll> I'll be working, can ping me if needed
15:26:15 <TheJulia> Okay, I might add a topic of larger scope that could be tied in or impact that... I need to think of the wording
15:26:31 <TheJulia> and the actual core idea, so I don't come off as the craziest of the crazy people
15:26:47 <TheJulia> If so, I'll try and co-ordinate
15:26:53 <jroll> sure, sounds good
15:27:03 <TheJulia> Is everyone good to proceed?
15:28:08 <rloo> ++
15:28:09 <rpittau> let's
15:28:16 <TheJulia> #topic Deciding on priorities for the coming week
15:28:25 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:28:30 <TheJulia> Starting at line 133
15:28:35 * TheJulia starts by removing merged
15:29:54 <TheJulia> dtantsur: I'm good with adding the allocation backfill
15:30:05 <dtantsur> cool, thx
15:30:39 <TheJulia> I think the list works
15:30:58 <TheJulia> Is there anything anyone else would like to see or have some people look at this week?
15:31:43 <kaifeng> I may help with the ipa-polling mode if that's in concern?
15:32:51 <TheJulia> kaifeng: Would you find it beneficial to your use cases?
15:33:47 <kaifeng> yes, it's avoid direct access to api during deployment
15:34:27 <jroll> kaifeng: you're more than welcome to take that on
15:34:29 <TheJulia> Okay, I believe you will also not be at the PTG, so perhaps we should possibly consider trying to schedule some time with jroll to discuss this a little fuirther
15:34:56 <jroll> I'm always here if it needs to be discussed
15:35:06 * TheJulia still needs to think of the crazy words and how to put them in the right order
15:35:08 <jroll> the spec should have everything, I hope :)
15:35:17 <kaifeng> TheJulia sigh, I am not there
15:35:32 <TheJulia> :(
15:35:34 <dtantsur> I think some team is having a pre-PTG. maybe it's a good idea?
15:35:36 <TheJulia> It is life sadly
15:35:59 <TheJulia> dtantsur: I think it is, lets see how discussion shapes up in the etherpad and go from there
15:36:03 <dtantsur> I mean, a virtual pre-PTG
15:36:04 <dtantsur> right
15:36:05 <kaifeng> jroll: thanks :)
15:36:09 <TheJulia> Excellent!
15:36:22 <TheJulia> Okay, I guess time for RFE review if there is nothing else on priorities for the coming week.
15:36:37 <TheJulia> #topic RFE Review
15:36:48 * TheJulia hands the micrphone to dtantsur
15:36:51 <TheJulia> microphone
15:38:03 <dtantsur> oh, me?
15:38:07 <TheJulia> yes :)
15:38:13 * TheJulia makes more coffee for dtantsur
15:38:21 <dtantsur> #link  https://storyboard.openstack.org/#!/story/2005328 Relax restrictions on network and storage interfaces
15:38:24 <dtantsur> yes, more coffee
15:38:31 <dtantsur> so, this was a request by IIRC eandersson
15:39:06 <dtantsur> tl;dr make all network interfaces work with all hardware types (something we explicitly avoided back in the driver composition reform times)
15:39:32 <TheJulia> I think that is reasonable, the is_compatible_with hw type check might need some fun logic for the first cycle or so
15:40:14 <TheJulia> I'm +2 on the new proposal
15:40:52 * rloo confused. remind me, what is the current restriction on network & storage interfaces?
15:41:10 <dtantsur> TheJulia: we can leave 'return True' there, as this is currently the case
15:41:26 <jroll> rloo: a hardware type hardcodes the supported interfaces
15:41:27 <dtantsur> rloo: they have to be enabled by the hardware type, the same way as power, management, etc
15:41:28 <rloo> what does (in the rfe) 'which so far have been practically universal' mean?
15:41:54 <dtantsur> rloo: meaning, I'm not aware of a mismatch between any hardware type and any network interface
15:41:55 <rloo> oh, so we don't want to hardcode for only network/storage interfaces?
15:42:06 <jroll> correct
15:42:07 <dtantsur> well, at least for now. we can talk about everything else later.
15:42:08 <rloo> but still hardcode for the other interfaces?
15:42:11 <dtantsur> yes
15:42:26 <TheJulia> eandersson's case is he is maintaining a downstream driver interface for his networking, and prsently he has to create new hardware types if he wants to use it, but he wants to use stock hardware types and just load up his new driver with the configuration
15:43:23 <rloo> which could be a similar thing for any interface driver? if eg someone has a downstream driver for console? (i can't remember if we have a console interface)
15:43:59 <rloo> anyway, i am +1 on the idea.
15:44:06 <rloo> need to read it all to be +2 :)
15:44:31 <TheJulia> that might be reasonable, maybe do this and then see how it goes because operators are more likely to do such things if they are empowered
15:44:39 <TheJulia> otherwise we're kind of handcuffing them
15:44:43 <rpioso> How might this affect in-tree vendor h/w types?
15:44:58 <TheJulia> it really won't affect in-tree h/w types
15:45:05 <jroll> rpioso: someone may use the in-tree h/w types with out of tree storage/network interfaces
15:45:08 <jroll> otherwise, no effect
15:45:35 <dtantsur> I'd defer discussion other interfaces until the PTG, but the storage/network seem easy
15:45:47 <jroll> ++
15:45:59 <rloo> i wonder if 'ANY' is the right word but maybe i'm shed biking.
15:46:16 <TheJulia> dtantsur: ++
15:46:19 <dtantsur> I'm open to suggestions :) this was based on mock.ANY
15:46:20 <TheJulia> sounds like we have RFE-approved
15:46:21 <rloo> we don't allow any, we allow compatible right? (any compatible)
15:46:44 <TheJulia> that was my interpretation
15:46:50 * rpioso is unclear on what supported_xxx_interfaces means?
15:47:01 <TheJulia> If there are no objections, we can proceed to Open Discussion
15:47:14 <dtantsur> rpioso: the properties on a HardwareType that regulate which interfaces are compatible with it
15:47:36 <dtantsur> rpioso: like here https://github.com/openstack/ironic/blob/master/ironic/drivers/drac.py#L38-L46
15:47:46 <rpioso> dtantsur: Wouldn't the RFE alter that concept?
15:47:53 <TheJulia> heh, dtantsur beat me with the link
15:48:10 * rpioso is familiar with the drac h/w type
15:48:22 <TheJulia> Changing to Open Discussion
15:48:27 <TheJulia> #topic Open Discussion
15:48:46 <TheJulia> While the other discussion continues, does anyone have anything specific they would like to raise today?
15:48:48 <jroll> rpioso: yes, it alters that concept, in that someone may now use the in-tree h/w types with out of tree storage/network interfaces
15:49:09 <rpioso> jroll: Thank you for answering my question :-)
15:49:10 * dtantsur wonders when we should start thinking about a get-together at the PTG
15:49:17 <jroll> rpioso: :)
15:50:20 <TheJulia> dtantsur: Hmm, yes. And we have more options not being at the old PTG venue in Stapleton, CO
15:50:26 <rloo> dtantsur: so we'd leave the current value of eg supported_network_interface as is?
15:50:54 <dtantsur> rloo: "Finally, update GenericHardware to add ANY for supported_storage_interfaces and supported_network_interfaces, thus making them universal."
15:51:13 <dtantsur> so no, add ANY (or whatever name we use) to them
15:51:51 * arne_wiebalck now gets what TheJulia was asking him the other day about network/storage interfaces
15:52:16 <rloo> dtantsur: thx, didn't read that far. i don't have enough time/thoughts to grok all the details of this now, so i will rely on the rest of you that are faster than me, to decide.
15:52:25 <rpittau> a couple of tests in ocata are failing for different reasons and wondering if we should fix them, they're in the patches related to the migration to gitea
15:52:32 <openstackgerrit> Merged openstack/bifrost master: Add git_branch variable  https://review.openstack.org/645518
15:52:51 <dtantsur> rpittau: it's a good question, ocata should have gone into extended maintenance already
15:53:12 <rpioso> dtanstur: I had the impression that the supported_xxx_interfaces declares, well, what's supported. Declaring ANY seems inconsistent with that concept.
15:53:14 <rpittau> dtantsur: yep, that's why I'm asking :/
15:53:56 <rpittau> example: https://review.openstack.org/646392
15:53:57 <patchbot> patch 646392 - ironic (stable/ocata) - Replace openstack.org git:// URLs with https:// - 1 patch set
15:54:04 <TheJulia> rpittau: we likely should fix them
15:54:12 <dtantsur> rpioso: well, that's the whole point here. what if a hardware type supports any network interfaces (which is the case of all our hardware types currently)?
15:54:22 * rloo wonders whether it makes sense for eg supported_network_interfaces to be eg 'flat_net.FlatNetwork, neutron.NeutronNetwork, ANY', so default can be explicitly specified.
15:55:01 <rloo> ^^ would be up to a specific hardware_type, in case they want to be explicit/suggest a default.
15:55:05 <dtantsur> TheJulia, rpittau, fixing the coverage job requires bumping test-requirements/upper-constraints or whatever
15:55:05 <rpittau> TheJulia: ok, I'll have a look then this week, shouldn't take too much time
15:55:24 <rpittau> dtantsur: yeah, it's the psycopg version
15:55:26 <dtantsur> rloo: that's exactly my plan
15:55:36 <dtantsur> (unless I misunderstood you)
15:55:47 <jroll> dtantsur: rpittau: coverage just runs tox-py27 and generates coverage. since py27 passed, it's probably just a problem with the pip cache
15:56:04 <jroll> (afaik)
15:56:16 <rpittau> jroll: it can be reproduced locally though
15:56:30 <jroll> ugh
15:56:38 <dtantsur> rpittau: oh, it may be that we don't use upper-constraints correctly
15:56:38 <rloo> dtantsur: guess it isn't clear to me, skimming the rfe. as long as that's your plan.
15:56:46 <dtantsur> for some long time we had a not-quite-valid approach
15:57:00 <TheJulia> Yeah, we had to fix it once before for one of the jobs
15:57:03 <rloo> rpioso: does that address your concerns (if i understand your concerns, if you have any concerns)
15:57:47 <rloo> rpioso, dtantsur: can i assume that if rpioso's HW type doesn't want to support ANY, that he can choose to have his hwtype not support ANY?
15:57:52 <rpioso> rloo: Yes, it does. Thank you!
15:57:54 <dtantsur> rloo: yes
15:58:01 <rpittau> btw there's one for rocky that has already +2 if anyone has 32.7 seconds https://review.openstack.org/647693
15:58:01 <patchbot> patch 647693 - networking-generic-switch (stable/rocky) - Fix pep8 test - 1 patch set
15:58:05 <TheJulia> 3 minute warning
15:58:19 <rloo> good, then everyone is happy this Monday :)
15:58:19 * dtantsur wonders how rpittau calculated that
15:59:18 <rajinir> devstack install fails on install_ironic
15:59:22 <rajinir> E: Package 'ovmf' has no installation candidate
15:59:38 <TheJulia> rajinir: where did you observe this?
15:59:43 <rpittau> oO
15:59:47 <TheJulia> Some packagers might be using different names
15:59:53 <rajinir> Dell Thirdparty CI is failing on UEFI boot mode
16:00:07 <TheJulia> rajinir: Example link?
16:00:19 <TheJulia> I guess that can be skipped in your CI since your using real hardware
16:00:29 <TheJulia> ovmf is for virtual machines only
16:00:42 <rajinir> logs:  https://stash.dellemc-community.org/logs/38/648938/2/check/dell-hw14G-UEFI-tempest-dsvm-ironic-idrac/911daec//
16:00:44 <rpittau> ovmf is loading from xenial mutliverse, might be the link is not accessible
16:00:52 <TheJulia> Thanks everyone!
16:00:57 <NobodyCam> :)
16:01:08 <rpioso> TheJulia: Thank you
16:01:31 <rajinir> rpittau: may be
16:01:43 <TheJulia> rajinir: That is also a Xenial build, you should likely switch to bionic
16:01:44 <rajinir> rpittau: TheJulia: This is new
16:02:03 <rpittau> rajinir: that looks outdated
16:02:39 <TheJulia> #endmeeting