17:00:00 #startmeeting ironic 17:00:00 Meeting started Mon Dec 19 17:00:00 2016 UTC and is due to finish in 60 minutes. The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:04 The meeting name has been set to 'ironic' 17:00:04 o/ 17:00:06 o/ 17:00:07 o/ 17:00:08 o/ 17:00:08 o/ 17:00:09 hey folks 17:00:09 o/ 17:00:14 o/ 17:00:18 o/ 17:00:37 as always, the agenda: 17:00:40 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:00:41 o/ 17:00:47 #topic announcements and reminders 17:00:59 you may be surprised to learn it's the holiday season 17:01:10 so expect it to be pretty quiet the next couple weeks 17:01:13 o/ 17:01:26 we agreed already to not meet december 26, and to meet january 2 for those that are working 17:01:45 TheJulia has a couple announcements as well 17:01:57 If there are no objections, I believe it is time for us to go ahead and remove ironic-webclient. With regards to doing so, I’ve already obtained the blessing of krotscheck who has indicated he does not intend to continue working on it. This should not be confused with ironic-ui. 17:02:03 For context: Ironic-webclient was created as a conceptual stand-alone UI interface to help drive CORS adoption. The original developer(s) have since changed employers and moved on to other things. It has been approximately six month since a change has landed in the repository, and there have been no releases to date. 17:02:19 also note most people at the summit were in favor of this 17:02:21 * jroll is +1 17:02:30 o/ 17:02:40 o/ 17:02:46 +1 on removal 17:03:02 Additionally, unrelated to the web client, the ironic-ui has had bugs added for functionality deficiencies where ironic supports something that the UI does not. 17:03:20 jroll: Thank you 17:03:30 oh, nice 17:03:33 \o/ 17:03:58 anyone have anything else? 17:04:07 TheJulia: so we have folks maintaining ironic-ui? 17:04:21 We are now fully a tempest plugin? 17:04:31 rloo: We do 17:04:47 we've been fully a tempest plugin, but good point - the tempest patch merged to remove ironic code from tempest's tree \o/ 17:04:48 TheJulia: I'll ping you later, will add a subteam for that 17:04:57 I managed to break inspector, but there's code up to fix that 17:05:00 rloo: Excellent! 17:05:29 yay for tempest plugin, boo for jroll breaking inspector :) 17:05:42 :) 17:05:55 indeed! 17:05:57 o/ 17:06:17 ok, let's move on 17:06:21 #topic subteam status updates 17:06:29 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:06:35 beginning at line 76 17:07:29 made some good progress on portgroups, driver composition, some CI/QA stuff this week 17:07:53 we should probably focus a bit harder on BFV this week, so TheJulia has some work to do while everyone else is taking time off :P 17:08:04 wrt portgroups support -- it mentions after the client stuff merges, needs nova patches. can the nova patches be done before attach/detach API? 17:08:11 Less rebasing \o/ 17:08:20 rloo: we agreed after attach/detach because it will be far simpler 17:08:28 actually, it will mean no changes in nova for portgroups iirc 17:08:43 (since it's all handled in attach/detach api) 17:08:45 jroll: that's what i thought. am going to update that subteam report for portgroups support 17:09:01 rloo: yeah, thanks, that was my report, oops 17:09:25 jroll: clarified :) 17:09:28 thanks 17:10:08 vsaienk0: wrt attach/detach, the client patches are up-to-date? 17:10:23 or whoever updated the attach/detach status.. ? 17:10:30 vdrok: ^^^ ? 17:10:48 rloo: I'm not sure about that 17:10:51 that might be from last week 17:11:02 vdrok: i just looked, the client patch was updated this morning 17:11:18 * jroll updates it 17:11:24 have not looked at the client yet 17:13:18 yay for inspector supporting upgrades and following standard deprecations! 17:13:32 * jroll \o/ 17:14:15 i saw that iBoot, WoL and AMT drivers have been removed; I'm going to remove AMT from the Drivers section of the subteam reports 17:14:28 ++ 17:14:45 that said, all these drivers are available at ironic-staging-drivers already 17:14:53 +1 17:14:54 for those that are still relying on them 17:16:00 jroll: wrt priorities, i would also like to get discussion/approval of rolling upgrades dbsync command 17:16:10 ++ 17:16:13 we need to do that asap 17:16:35 jroll: was going to put it as #4. what are you thinking? #2? 17:16:51 I'm fine with #2 17:16:57 jroll: will do 17:17:03 or we could just get it done in channel today and not worry 17:17:55 jroll: that's my plan :) 17:18:00 cool 17:18:09 any other questions/comments here? 17:18:58 None here 17:19:13 #topic Granting +1/-1 rights to OPNFV CI for Bifrost Patches 17:19:17 TheJulia: this is you 17:19:21 Fdegir couldn't make it to the meeting today, so I'll be the stand-in. 17:19:31 Fdegir is with OPNFV, and they have been running a fairly stable third party CI for Bifrost for a while now. OPNVF is interested in obtaining CI voting rights on bifrost in order to help gate any breaking changes since they are utilizing bifrost heavily. 17:19:41 I have no objections with this, but wanted to run it past the larger community. 17:20:01 is there data on the stability? 17:20:38 My anecdotal observations have been that it appears to be about as stable as openstack ci it's self, however I've not hunted down any statistics 17:20:48 also can we clarify what "voting" means? can a patch still merge with it voting -1? (I'm fairly certain that third party CI isn't allowed to actually block) 17:21:18 iirc voting third party CI just means their name is next to jenkins at the top in the vote list, or something 17:21:30 Voting would be that the test would vote as a CI system. It is not forbidden from what I understand, it is just discouraged because of potential headaches 17:21:38 TheJulia, you can create a graph at http://graphite.openstack.org to check the failure rate (after the meeting idk) 17:22:37 TheJulia: so a -1 from this CI means a patch cannot merge, correct? 17:22:40 lucasagomes: Yeah, I should do that. 17:22:47 jroll: As I understand it, yes 17:22:47 * jroll feels like he needs to dig up clarity 17:23:07 last question for now, is there a patch up for this already? 17:23:38 jroll: no, it is a permission grant in garrit. The group already exists, their CI is just not a member to give it the ability to vote yet 17:23:46 gerrit 17:24:11 o/ 17:24:12 TheJulia: ah 17:24:32 I think I need to learn a bit more about this, honestly, I wish I had read up first 17:24:45 Well, I'm fine with revisiting it a little later then 17:24:49 I also see the process involves an email with data: http://docs.openstack.org/infra/system-config/third_party.html#permissions-on-your-third-party-system 17:25:34 Hmm, that seems a little different from the last time I read that, but that was months ago. 17:26:10 So, defer, collect more information, and go from there. 17:26:20 yeah, I think so 17:26:24 Sounds good to me 17:26:34 or we could kick off the ML thread now (or maybe in january) and gather info there 17:26:54 any last comments? 17:27:02 anyone, not just julia :P 17:27:04 I suspect January would be best considering how quiet it will be the next few weeks. I'll check-in with fdegir first. 17:27:34 cool 17:27:59 thanks TheJulia :) 17:28:10 My pleasure :) 17:28:13 thx TheJulia! (I'm good with it but i don't use bifrost so my vote doesn't really count) 17:28:13 #topic open discussion 17:28:18 who's got a thing :) 17:28:37 * TheJulia hears crickets 17:28:57 great, I'm hungry :P 17:29:04 I have 17:29:04 :) 17:29:15 joanna: go ahead 17:29:22 so... I was working on a bug: https://bugs.launchpad.net/ironic/+bug/1461140 17:29:23 Launchpad bug 1461140 in Ironic "conflict (HTTP 409) incorrect for some cases" [Medium,In progress] - Assigned to Joanna Taryma (jtaryma) 17:29:51 I read the discussion posted in comments, and in my latest comment you can read what I got 17:30:09 * lucasagomes reads 17:30:29 keeping it short - 409 cannot be replaced with 423 locked for node locked situation cause it's not a valid http response code 17:30:42 joanna: did we decide to have 423 for locked? 17:30:43 joanna: According to what is it not a valid code? 17:30:53 joanna: I mean, what complains about that code? 17:31:10 jlvillal: six, so it seems 17:31:14 which uses stdlib 17:31:20 wsmeext.pecan in response validation check python http client's responses dict 17:31:25 and 423 is not here 17:31:34 Ah 17:31:51 I think this is because it's WebDAV 17:32:07 yeah I think pecan won't accept WebDAV 17:32:16 joanna, what about the Retry-After: header ? 17:32:18 (standard for distributed document edition) 17:32:24 also, I think here is an rfc on http status codes https://tools.ietf.org/html/rfc7231.html 17:32:29 no 423 here 17:32:31 we could have the Retry-After set for the exceptions that are retryable 17:32:41 if non-retryable we emit the header 17:32:52 this is about changing the response codes for things like "node with duplicate name" or "delete node with instance" 17:32:53 I got stuck on the code, lucadagomes 17:33:02 fwiw, not about changing node locked exceptions 17:33:13 jroll: what? 17:33:27 rloo: anything that can be retried successfully 17:33:30 jroll: shouldn't it just be 400 then? 17:33:37 jroll, yeah, I think so 17:33:41 rloo: reading the bug, it seems we want to change it for those cases, not for locked cases 17:33:43 nope, exactly the opposite 17:33:53 rloo, actually 409 (conflict) is correct for such errors 17:33:57 afaict 17:33:59 409 is perfect for duplicate names 17:34:13 (and ids and addresses and other stuff) 17:34:22 it was created for such cases 17:34:25 then I'm confused, I guess, or didn't read the discussion that goes the opposite way of the bug description 17:34:28 it's just that we abuse of 409 for things such node locked 17:34:30 yet, I agree that node locked is not 409 17:34:44 (note I didn't say I agree with the bug description, just pointed out that's what it says) 17:35:12 jroll: yeah, i wrote that bug description early on. it needs to be updated to reflect the discussion we had a long time ago. 17:35:16 jroll, imho this IRC discussion gives this bug a direction :) 17:35:21 so If I understand correctly, client always retries on 409, while we should do it only in cases when we actually can retry and get a success 17:35:35 rloo - I can rewrite it following the discussion 17:35:41 rloo: yes, updating the description would be helpful to be able to talk about the bug 17:35:42 vdrok, that's my understanding as well 17:35:53 joanna: we already had a discussion awhile ago -- what was decided in that earlier discussion? 17:36:27 it shouldn't retry on 409 imho - because if a name/id/sth is in use it will fail anyway 17:36:44 on node locked it should becuase it might have been freed up in the meantime 17:36:45 when eg we set standalone_ports_supported on a portgroup that has pxe_enabled ports in it, we throw conflict, but the client should not retry, it should be resolved first 17:37:21 reading that irc discussion, we agreed there is a problem, and lucasagomes and dtantsur were going to put a plan together to fix it. part of the problem was too many locks, part was too many retries. 17:37:32 joanna: Can you also give an example of the error pecan is throwing using 423? 17:37:42 and we would discuss the status code to replace 409 in the spec. 17:38:03 the problem of changing 409 is that old clients will not retry on the new return code 17:38:10 it ended up with 'we have to do a research' 17:38:20 jlvillal: 423 is not a valid status code, per the RFE, so I'm kind of against it anyway :) https://tools.ietf.org/html/rfc7231.html 17:38:20 joanna, that's why I was thinking whether continue to use 409 + a header would be better 17:38:50 we might use the prerequisite not ready + retry 17:38:58 at least with the backward compat POV in it, we could have a header that the client checks to know whether it should retry or not when a 409 is raised 17:39:03 jroll: so i think we need a spec and we can move this discussion to that spec 17:39:09 when the node is locked, and 409 for conflicts + no retry 17:39:19 I like the header idea too 17:39:36 jroll: Well it is valid in this other RFC... https://tools.ietf.org/html/rfc2518 But point taken. 17:40:00 lucasagomes: then all conflicts that will fail by definition would create unnecessary traffic 17:40:16 jlvillal: which is an http extension for distributed authoring, dunno if it applies here 17:40:28 also... 17:40:58 I don't think that using 204 code as a POST response is valid 17:41:25 would you all be fine with me preparing a spec about tidying up the responses? 17:41:57 joanna, that would be another problem, kinda off topic 17:42:03 joanna, but I'm good with the spec yeah 17:42:07 hm ,why? 204 just means that there is no content in response 17:42:07 yeah, I'd prefer to solve the locking thing 17:42:19 not really interested in debating semantics of 200 vs 204 for post requests 17:42:21 it's sort of off topic, but the spec could be more generic the 17:42:24 then* 17:42:39 204 is not a response for POST 17:42:46 201 created should be sent 17:43:10 joanna, well, by experience. This type of spec will take way more time to get merged than if you focus on one problem at time 17:43:24 you can fix the return codes in parallel, I think we should have a separated spec for the locking 17:43:33 but it's up to you 17:43:49 fixing/changing the return codes will require, at minimum, and RFE 17:43:51 lucasagomes, +1 less bikeshedding 17:44:01 s/and/an/ 17:44:07 lucasagomes, thanks it is a good advice! :) 17:44:39 rloo - can I treat that bug as an RFE? 17:44:52 (rename the name of the bug?) 17:45:01 up to you, as long as it is clear what it is. 17:45:28 joanna: or just create a new rfe and link/point the existing bug to it. 17:45:40 joanna: i don't think we care that much. as long as it describes the problem, etc. 17:46:02 OK, as it already needs rewriting, I think I'll create a new one and a link 17:46:07 thanks, rloo 17:46:26 cool, so we're good here? 17:46:38 anything else for open discussion? 17:46:40 yes, thanks all 17:46:49 joanna, thank YOU for fixing it :-) 17:47:14 i haven't fixed it... yet ;) 17:47:25 for trying :D 17:47:31 heh 17:47:38 obligatory gl;hf :P 17:47:45 thanks for a good meeting all :) see you back in channel 17:47:50 thanks! 17:47:54 #endmeeting