17:00:04 #startmeeting ironic 17:00:05 Meeting started Mon Jun 26 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:07 o/ 17:00:10 The meeting name has been set to 'ironic' 17:00:24 hi everyone! 17:00:29 o/ 17:00:31 who is here for the ironic meeting? 17:00:31 o/ 17:00:39 o/ 17:00:51 o/ 17:01:06 o/ 17:01:14 our agenda as usual is here: 17:01:23 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:50 o/ 17:02:12 o/ 17:02:23 #topic Announcements / Reminder 17:02:29 o/ 17:02:36 #info Work has started to import the IPA DIB element under our governance (RFE https://bugs.launchpad.net/ironic/+bug/1700071) 17:02:37 Launchpad bug 1700071 in Ironic "[RFE] Make DIB-build IPA fully supported" [Wishlist,Confirmed] - Assigned to Dmitry Tantsur (divius) 17:02:43 this was discussed on the PTG 17:02:58 I want to give a heads up that I've started the process with requesting a new repository to host our build tools 17:03:08 o/ 17:03:10 o/ 17:03:14 thx dtantsur 17:03:36 I'm on 17:04:17 anything else? 17:04:33 don't know if we want to discuss whether there is a meeting next week 17:04:41 it is a US holiday for some I think 17:04:46 ah 17:04:58 I'm focus on UEFI secure boot. I hope new ironic-python-agent-builder can support UEFI secure boot 17:05:02 I believe the holiday is on Tuesday 17:05:16 TheJulia: right, July 4 is. i think some people get Mon off 17:05:17 well, we tend not to cancel meetings for holiday in one country. do you think we should? 17:05:32 dtantsur: only cancel if there aren't enough people. that's why i'm asking. 17:05:44 dtantsur: not related to that, but i won't be here next Mon 17:05:45 rloo: it would vary by company, most that I'm aware of will have tuesday off 17:06:04 We (Intel) are on holiday for Monday & Tuesday in the US 17:06:24 I suggest trying to start it and cancelling if there is no presence 17:06:25 dtantsur: what is this RFE for? could you detail it a bit? :) 17:06:26 well, i don't see a big show of hands not having a meeting, so lets assume there is a meeting next Mon. 17:06:52 xavierr: 700071? We're going to move the DIB element to build IPA from DIB tree to our repo 17:06:58 I say hold the meeting, if there isn not a quorum, then so be it, if there is then awesome 17:07:06 and then work on CI coverage for it to declare DIB officially supported 17:07:33 dtantsur: what we understand by DIB element? 17:07:56 xavierr: https://docs.openstack.org/developer/diskimage-builder/elements/ironic-agent/README.html 17:08:08 this is used by TripleO and a few other folks to build an image 17:08:50 xavierr: we can chat later, if you're interested in more details 17:08:55 anything else? 17:09:07 dtantsur: ty, let's go ahead 17:09:16 #topic Review subteam status reports (capped at ten minutes) 17:09:23 dtantsur, I hope new ironic-python-agent-builder can support UEFI secure boot 17:09:33 our exciting stuff is listed on the white board: 17:09:35 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:09:49 we have 2 critical bugs? or are those the same ones that are now ok? 17:09:52 tuanla_fujitsu: we'll migrate whatever DIB supports now. 17:09:58 rloo: both for gate 17:10:11 I'm not sure if we can close them, as in both cases we had reverts 17:10:15 dtantsur: ok, and gate is working (we think) 17:10:25 especially the glance one: it will certainly be applied again one day 17:10:33 we can lower them both to high now 17:10:41 dtantsur: not critical any more, lower them ++ 17:10:49 ok 17:10:57 * dtantsur needs to list critical bugs on his dashboard 17:11:16 mtreinish: Is asking over in #openstack-qa when we will fix glance. 17:11:26 I'm assuming he wants to get that patch back into devstack 17:12:11 jlvillal: thanks, that's what I expected 17:12:14 jlvillal: oh. i guess we need to get dtantsur's hack patch in then 17:12:21 my patch is under a recheck currently 17:12:22 s/hack/beautiful/ 17:12:35 hack == beautiful and if anyone disagrees... 17:12:45 heh 17:12:52 dtantsur: I've changed to high the one about grenade 17:12:54 jlvillal: yes it was some effort to get everything working, so I want to revert the revert 17:13:13 thanks vdrok 17:13:24 mtreinish: noted, thanks. 17:13:35 mtreinish: our gate broke, but looks like it may be fixed, if so, will get something in soonish, 1-2 days... 17:13:50 dtantsur: Do you have a test on your patch to see what happens if the revert^2 happens? 17:14:00 jlvillal: nope, this is something we need now 17:14:35 * jlvillal looks into it 17:14:39 though I need to check if it passed the CI *before* the revert has happened 17:15:19 i have a question about networking -- there is a nova side to post-deploy VIF attach/detach. i haven't looked at it. does it need ironic attention? does it need to land before nova's feature freeze in july? 17:15:34 sambetts ^^ L212 17:15:43 regarding CI, are you able to access the status: http://ci-watch.tintri.com/ ? 17:15:55 gah, electricity will be turned off in the office in 10 mins. /me runs away. rloo I've updated the nova patch a bit, I suppose the ironic side is done 17:16:01 rloo: yes there is: https://review.openstack.org/#/c/419975/ 17:16:42 rloo: there have been a view back and forths about what should and shouldn't be marked by a microversion but I think its progressing 17:17:04 vdrok, sambetts: ok, let us know if we need to look at that soonish rather than laterish. (and if we don't at all, even better!) 17:18:50 dtantsur: qq, don't know if you have paid attention to the doc proposal about moving docs intree in projects. do we have to make those changes in pike? 17:19:19 John L. Villalovos proposed openstack/ironic master: Testing dtantsur's glance uswgi fix https://review.openstack.org/477614 17:20:05 rloo: I think the more attention on the nova patch to bump it up the review queue the better :) 17:20:38 sambetts: which is higher priority, that or physical network awareness? 17:21:08 rloo: I don't think so? The spec is not merged yet. It's not hard to do though, so we *may* end up doing it in Pike anyway. 17:21:24 dtantsur: ok 17:21:30 there is a good instruction (in the spec) on how to do it. if there is a volunteer, they can go ahead 17:21:50 otherwise I'll try to dedicate some time for it after the spec is merged 17:22:15 dtantsur: after the spec merged, let's ask for volunteer first before you do it. i think your time is more valuable elsewhere. 17:22:22 ++ 17:22:52 I'm done with the statuses. Overall, I feel like certain things will not make it. I wonder if we want to discuss it one day soon.. 17:23:29 rloo: the ironic side the attach/detach has already landed, and the nova side I think is an easy win it just needs attention 17:23:40 sambetts: okey dokey 17:24:28 * sambetts has got to run, if you need me for any questions mention me and I'll try to follow up in the morning 17:25:16 it's becoming a tradition that status review capped at ten minutes takes more than 15 :) 17:25:30 I don't mind it, maybe we should allocate more time (or less priorities) 17:25:42 I would lean towards less priorities 17:25:44 personally 17:25:58 dtantsur: either fewer priorities or more time, both work for me. 17:26:20 I think for Queens the number of priorities we have to be substantially less 17:26:20 dtantsur: i'm fine leaving our tradition for pike though :-) 17:26:25 ok :) 17:26:28 let's move on? 17:26:34 ++ 17:26:54 #topic Deciding on priorities for the coming week 17:27:08 of 5 patches, one is travelling through the gate on its way to git.openstack.org 17:27:23 I think the gate breakages hurt our velocity :( 17:27:37 jlvillal: I know it did 17:27:39 yep. should we replace the nearly-merged patch with something else? 17:28:05 dtantsur: yeah, the nova patch :-) 17:28:32 rloo: it's not really actionable from our side? 17:28:42 dtantsur: or i know these aren't on the priorities, the patches to fix the gate 17:28:45 I mean, it's totally a priority, but all we can do is nag nova folks 17:28:50 dtantsur: reviews? 17:29:17 dtantsur: we can review the nova patch 17:29:22 right 17:29:36 * dtantsur has problems with internet 17:29:45 #chair TheJulia rloo 17:29:46 Current chairs: TheJulia dtantsur rloo 17:29:57 just in case I drop our ^^^ 17:30:01 ok 17:30:59 ok, added the nova patch 17:31:20 should we add the whole glance access refactoring chain? 17:31:25 dtantsur: you're pretty close on the classic driver deprecation spec, right? 17:31:31 starting with my patch and going on with pas-ha's? 17:31:41 rloo: yep, some comments to address (IIRC minor) 17:31:55 dtantsur: i haven't looked at the glance access chain recently, is it ready for reviews? 17:32:03 w/r/t bfv, might be worth adding the next bfv patch (https://review.openstack.org/#/c/463930/14) It is fairly boiler plate but it is required before the API can be landed 17:32:18 the physnet patch ended up getting blocked by other things. I'm trying to fix those things to unblock it 17:32:36 mgoddard: should we drop it til next week then? 17:33:05 perhaps that would be sensible 17:33:29 okay, we'll get it back next week hopefully 17:33:56 we have 5 code patches and one spec. enough? :) 17:33:57 there will be a few ironic patches that will need to go in before the next physnet patch 17:34:15 dtantsur: too many :-) 17:34:31 mgoddard: please update the whiteboard when you know what the first patch of the new chain is :-) 17:35:09 wrt bfv, did we land some API changes already? 17:35:17 rloo: will do 17:35:18 rloo: anything you would drop? 17:35:32 rloo: nope, we're holding them until we can the actual code in place 17:35:54 dtantsur: oh i didn't realize that, ok then. (cuz CRUD can't go in before API) 17:36:09 fine to leave those as priorities, we'll get done what we get done :-) 17:36:32 rloo: "CRUD cannot go in before API" is a good point, actually 17:36:42 TheJulia, mjturek, shouldn't we rearrange them ^^^? 17:37:33 why can't the notifications go in until after the api? 17:37:48 seems like we would want the substrate... 17:38:03 well, we can't notify users about entities that don't exist in the API, right? 17:38:08 dtantsur: i am working on a patch wrt rolling upgrades, to support port.physical_network and a few tweaks. would be nice to get eyes on that when it is ready, but i can ping folks later this week. 17:38:32 dtantsur: but they wouldn't be sent until the api endpoints land... 17:38:54 also fair.. I guess I don't care too much, I just want the API asap 17:39:10 The crud stuff is very boilerplate 17:39:19 TheJulia: there was a reason but i can't recall now what it was. if i do, i'll let you know. or maybe that reason is no longer. 17:39:27 The API stuff is also very boilerplate and has been in review in various forms for well over a year 17:39:58 TheJulia: is the API stuff ready to review and waiting? I don't see it in the top priorites to be reviewed? 17:40:06 ok, let's check the notifications patch, and rearrange them if we need to 17:40:07 rloo: if there is a good reason, We can always restack patches, it just seems like we would want them before not after 17:40:28 ok with the other priorities? 17:40:34 rloo: the api has been up for reviews for a long... long time. 17:40:51 TheJulia: so my question is, CAN the API code get merged if it is OK? 17:41:05 rloo: I believe so yes 17:41:08 stuff being ready for review for a long time exists all over the place 17:41:26 It has been maintained as we have added decoraters/security changes, etc. 17:41:28 TheJulia: if that is the case, why isn't it at the top of your bfv food chain? I mean, if you think it should go in before the other bfv patches 17:41:56 TheJulia: i have not been paying attention to bfv, so if i am asking dumb questions or not understanding what we are discussing now... 17:42:03 rloo: because the substrate must be present prior the api being available 17:42:09 well, we should not land API before it's functional 17:42:14 if the substrate is not functional, then.. the api is useless 17:42:20 TheJulia: so if the substrate is not available then NO, the API is not ready to go in. 17:42:41 rloo: hence why it is further down on the ironic BFV etherpad 17:42:42 notifications is a different thing: we can live without them for a week or two 17:43:04 do we want to move the api to be rooted directly off of the wire-in patch? 17:43:08 Maybe I shouldn't have taken so literally that some code has been ready for reviews for a long time. (cuz that is the case for lots of other patches) 17:43:29 because if so, I'll grab a beer and do it right after the meeting 17:43:50 I'm fine with how it is now, for the record 17:44:22 I've got +2 on the crud stuff, it seems boiler plate to me, we can always proceed to the next patch which is the api from there. Or not *shrugs* 17:44:42 One downside of so many people working on this though, is if we begin to change the patch order, things might get squashed easier 17:44:58 but, I suspect there is not much to be done in those patches, or fixes can be done with follow-ups 17:45:00 if necessary. 17:45:16 * rloo now wonders how long we allocate for deciding on the week's priorities :-) 17:45:24 rloo: who knows ;) 17:45:27 as much as we need, I guess :D 17:45:31 but that's a good conversation 17:45:56 rloo: are you ok with the list or should we dig into patch ordering? or should we just have a placeholder ? 17:46:02 ++; perhaps move the bfv conversation to their weekly meeting 17:46:05 dtantsur: i'm ok with the lsit 17:46:08 s/lsit/list/ 17:46:09 cool! 17:46:23 #topic Expiring old bugs 17:46:35 dtantsur: want me to put placeholders in for the entire chain? 17:47:00 I've noticed some teams do it 17:47:00 while it seems not too friendly to people reporting bugs, chances are very low someone is going to pick a year-old bug 17:47:08 TheJulia: I'm personally fine with what we have now. 17:47:09 I'm all for expiring bugs older than 1 year 17:47:14 dtantsur: 0k 17:47:16 err ok 17:47:34 thanks 17:47:35 any other opinions on bugs expire? 17:47:37 * rloo recalls why we didn't do crud before API -- that was for existing notifications that were updated due to eg a new field. If this is the first time, v1.0, it is fine. 17:48:10 rloo: ++ that was it 17:48:16 rloo: thanks! 17:48:41 i think we had discussed bug expiration before but i don't recall what we had decided, and that was when ironic was younger. i think it is reasonable to expire them now. 17:49:16 dtantsur: thinking of automating the expiration? 17:49:30 yeah 17:49:52 rloo: this is a good question. some common sense may be useful, I'd prefer to do it by hand. 17:50:14 I mean, some bugs may be obviously still valid and important. but I expect that to be a small percent 17:50:22 dtantsur: in that case, i realize it may be useful, but given the (smaller)number of folks, i'd rather the bugs languish in bug-land and people review. 17:50:58 I can take a dozen each week, and we'll get rid of them in a few months 17:51:13 what does it matter that the bugs don't expire, unless you don't like the number of them?' 17:51:27 sorry? 17:51:37 dtantsur: i'd rather you review patches than do this. 17:51:49 I'm fine with an automation, just dunno if we're going to throw away anything really important 17:51:53 If we have a volunteer, we should do it 17:52:21 rloo: okay, then let's agree on it, I'll announce it on the ML and will call for a volunteer 17:52:47 + dtantsur, because now we have 415 Open bugs on ironies project 17:52:53 right 17:53:12 i guess that's one of my points, i personally don't care that we have 415 open bugs. 17:53:16 any objections to find a volunteer to review (quickly) and close the old bugs? 17:53:22 7 minute warning 17:53:40 dtantsur: no objection here 17:54:15 rloo: well, it may confuse new contributors. and it does not allow us to see the real picture: how many actual bugs do we have? 17:54:42 dtantsur: that was one of my questions, what does it matter. for ^^ reasons. 17:55:07 5 minute warning 17:55:22 dtantsur: i just don't see it as a high priority given everything else on our plate. just saying. 17:55:44 yeah, that's why I won't do it myself 17:55:53 I'm trying to figure out our official policy on old bugs 17:56:45 any more comments here? I guess we don't have a clear agreement.. 17:57:07 i think we're good with expiring 1 year+ bugs. just the execution... 17:57:16 agreed 17:57:40 Agree rloo and dtantsur 17:57:53 #agreed Bugs older than 1 year may be expired 17:58:15 anything else before we wrap up? 17:58:18 votes for a python script ;) 17:58:31 jlvillal: talk to sdague ;) 17:58:55 yeah, I've noticed him doing that, and decided to cargo-cult this practice :) 17:59:05 okay, thanks everyone! 17:59:17 Thank you everyone 17:59:35 Bye. Good night 17:59:52 Bye 17:59:56 #endmeeting