17:00:00 <jroll> #startmeeting ironic
17:00:00 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:04 <openstack> The meeting name has been set to 'ironic'
17:00:04 <TheJulia> o/
17:00:06 <vdrok> o/
17:00:07 <xek> o/
17:00:08 <mariojv> o/
17:00:08 <zhenguo> o/
17:00:09 <jroll> hey folks
17:00:09 <joanna> o/
17:00:14 <galyna> o/
17:00:18 <jlvillal> o/
17:00:37 <jroll> as always, the agenda:
17:00:40 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:41 <rloo> o/
17:00:47 <jroll> #topic announcements and reminders
17:00:59 <jroll> you may be surprised to learn it's the holiday season
17:01:10 <jroll> so expect it to be pretty quiet the next couple weeks
17:01:13 <aslezil> o/
17:01:26 <jroll> we agreed already to not meet december 26, and to meet january 2 for those that are working
17:01:45 <jroll> TheJulia has a couple announcements as well
17:01:57 <TheJulia> 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 <TheJulia> 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 <jroll> also note most people at the summit were in favor of this
17:02:21 * jroll is +1
17:02:30 <bfournie> o/
17:02:40 <cdearborn> o/
17:02:46 <jlvillal> +1 on removal
17:03:02 <TheJulia> 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 <TheJulia> jroll: Thank you
17:03:30 <jroll> oh, nice
17:03:33 <jroll> \o/
17:03:58 <jroll> anyone have anything else?
17:04:07 <rloo> TheJulia: so we have folks maintaining ironic-ui?
17:04:21 <jlvillal> We are now fully a tempest plugin?
17:04:31 <TheJulia> rloo: We do
17:04:47 <jroll> 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 <rloo> TheJulia: I'll ping you later, will add a subteam for that
17:04:57 <jroll> I managed to break inspector, but there's code up to fix that
17:05:00 <TheJulia> rloo: Excellent!
17:05:29 <rloo> yay for tempest plugin, boo for jroll breaking inspector :)
17:05:42 <jlvillal> :)
17:05:55 <jroll> indeed!
17:05:57 <xavierr> o/
17:06:17 <jroll> ok, let's move on
17:06:21 <jroll> #topic subteam status updates
17:06:29 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:06:35 <jroll> beginning at line 76
17:07:29 <jroll> made some good progress on portgroups, driver composition, some CI/QA stuff this week
17:07:53 <jroll> 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 <rloo> 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 <TheJulia> Less rebasing \o/
17:08:20 <jroll> rloo: we agreed after attach/detach because it will be far simpler
17:08:28 <jroll> actually, it will mean no changes in nova for portgroups iirc
17:08:43 <jroll> (since it's all handled in attach/detach api)
17:08:45 <rloo> jroll: that's what i thought. am going to update that subteam report for portgroups support
17:09:01 <jroll> rloo: yeah, thanks, that was my report, oops
17:09:25 <rloo> jroll: clarified :)
17:09:28 <jroll> thanks
17:10:08 <rloo> vsaienk0: wrt attach/detach, the client patches are up-to-date?
17:10:23 <rloo> or whoever updated the attach/detach status.. ?
17:10:30 <jlvillal> vdrok: ^^^ ?
17:10:48 <vdrok> rloo: I'm not sure about that
17:10:51 <jroll> that might be from last week
17:11:02 <rloo> vdrok: i just looked, the client patch was updated this morning
17:11:18 * jroll updates it
17:11:24 <vdrok> have not looked at the client yet
17:13:18 <rloo> yay for inspector supporting upgrades and following standard deprecations!
17:13:32 * jroll \o/
17:14:15 <rloo> 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 <lucasagomes> ++
17:14:45 <lucasagomes> that said, all these drivers are available at ironic-staging-drivers already
17:14:53 <jroll> +1
17:14:54 <lucasagomes> for those that are still relying on them
17:16:00 <rloo> jroll: wrt priorities, i would also like to get discussion/approval of rolling upgrades dbsync command
17:16:10 <jroll> ++
17:16:13 <jroll> we need to do that asap
17:16:35 <rloo> jroll: was going to put it as #4. what are you thinking? #2?
17:16:51 <jroll> I'm fine with #2
17:16:57 <rloo> jroll: will do
17:17:03 <jroll> or we could just get it done in channel today and not worry
17:17:55 <rloo> jroll: that's my plan :)
17:18:00 <jroll> cool
17:18:09 <jroll> any other questions/comments here?
17:18:58 <TheJulia> None here
17:19:13 <jroll> #topic Granting +1/-1 rights to OPNFV CI for Bifrost Patches
17:19:17 <jroll> TheJulia: this is you
17:19:21 <TheJulia> Fdegir couldn't make it to the meeting today, so I'll be the stand-in.
17:19:31 <TheJulia> 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 <TheJulia> I have no objections with this, but wanted to run it past the larger community.
17:20:01 <jroll> is there data on the stability?
17:20:38 <TheJulia> 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 <jroll> 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 <jroll> 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 <TheJulia> 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 <lucasagomes> TheJulia, you can create a graph at http://graphite.openstack.org to check the failure rate (after the meeting idk)
17:22:37 <jroll> TheJulia: so a -1 from this CI means a patch cannot merge, correct?
17:22:40 <TheJulia> lucasagomes: Yeah, I should do that.
17:22:47 <TheJulia> jroll: As I understand it, yes
17:22:47 * jroll feels like he needs to dig up clarity
17:23:07 <jroll> last question for now, is there a patch up for this already?
17:23:38 <TheJulia> 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 <TheJulia> gerrit
17:24:11 <milan> o/
17:24:12 <jroll> TheJulia: ah
17:24:32 <jroll> I think I need to learn a bit more about this, honestly, I wish I had read up first
17:24:45 <TheJulia> Well, I'm fine with revisiting it a little later then
17:24:49 <jroll> 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 <TheJulia> Hmm, that seems a little different from the last time I read that, but that was months ago.
17:26:10 <TheJulia> So, defer, collect more information, and go from there.
17:26:20 <jroll> yeah, I think so
17:26:24 <TheJulia> Sounds good to me
17:26:34 <jroll> or we could kick off the ML thread now (or maybe in january) and gather info there
17:26:54 <jroll> any last comments?
17:27:02 <jroll> anyone, not just julia :P
17:27:04 <TheJulia> 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 <jroll> cool
17:27:59 <jroll> thanks TheJulia :)
17:28:10 <TheJulia> My pleasure :)
17:28:13 <rloo> thx TheJulia! (I'm good with it but i don't use bifrost so my vote doesn't really count)
17:28:13 <jroll> #topic open discussion
17:28:18 <jroll> who's got a thing :)
17:28:37 * TheJulia hears crickets
17:28:57 <jroll> great, I'm hungry :P
17:29:04 <joanna> I have
17:29:04 <joanna> :)
17:29:15 <jroll> joanna: go ahead
17:29:22 <joanna> so... I was working on a bug: https://bugs.launchpad.net/ironic/+bug/1461140
17:29:23 <openstack> Launchpad bug 1461140 in Ironic "conflict (HTTP 409) incorrect for some cases" [Medium,In progress] - Assigned to Joanna Taryma (jtaryma)
17:29:51 <joanna> 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 <joanna> 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 <rloo> joanna: did we decide to have 423 for locked?
17:30:43 <jlvillal> joanna: According to what is it not a valid code?
17:30:53 <jlvillal> joanna: I mean, what complains about that code?
17:31:10 <jroll> jlvillal: six, so it seems
17:31:14 <jroll> which uses stdlib
17:31:20 <joanna> wsmeext.pecan in response validation check python http client's responses dict
17:31:25 <joanna> and 423 is not here
17:31:34 <jlvillal> Ah
17:31:51 <joanna> I think this is because it's WebDAV
17:32:07 <lucasagomes> yeah I think pecan won't accept WebDAV
17:32:16 <lucasagomes> joanna, what about the Retry-After: header ?
17:32:18 <joanna> (standard for distributed document edition)
17:32:24 <vdrok> also, I think here is an rfc on http status codes https://tools.ietf.org/html/rfc7231.html
17:32:29 <vdrok> no 423 here
17:32:31 <lucasagomes> we could have the Retry-After set for the exceptions that are retryable
17:32:41 <lucasagomes> if non-retryable we emit the header
17:32:52 <jroll> this is about changing the response codes for things like "node with duplicate name" or "delete node with instance"
17:32:53 <joanna> I got stuck on the code, lucadagomes
17:33:02 <jroll> fwiw, not about changing node locked exceptions
17:33:13 <rloo> jroll: what?
17:33:27 <vdrok> rloo: anything that can be retried successfully
17:33:30 <rloo> jroll: shouldn't it just be 400 then?
17:33:37 <lucasagomes> jroll, yeah, I think so
17:33:41 <jroll> rloo: reading the bug, it seems we want to change it for those cases, not for locked cases
17:33:43 <joanna> nope, exactly the opposite
17:33:53 <lucasagomes> rloo, actually 409 (conflict) is correct for such errors
17:33:57 <lucasagomes> afaict
17:33:59 <joanna> 409 is perfect for duplicate names
17:34:13 <joanna> (and ids and addresses and other stuff)
17:34:22 <joanna> it was created for such cases
17:34:25 <jroll> then I'm confused, I guess, or didn't read the discussion that goes the opposite way of the bug description
17:34:28 <lucasagomes> it's just that we abuse of 409 for things such node locked
17:34:30 <joanna> yet, I agree that node locked is not 409
17:34:44 <jroll> (note I didn't say I agree with the bug description, just pointed out that's what it says)
17:35:12 <rloo> 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 <joanna> jroll, imho this IRC discussion gives this bug a direction :)
17:35:21 <vdrok> 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 <joanna> rloo - I can rewrite it following the discussion
17:35:41 <jroll> rloo: yes, updating the description would be helpful to be able to talk about the bug
17:35:42 <lucasagomes> vdrok, that's my understanding as well
17:35:53 <rloo> joanna: we already had a discussion awhile ago -- what was decided in that earlier discussion?
17:36:27 <joanna> it shouldn't retry on 409 imho - because if a name/id/sth is in use it will fail anyway
17:36:44 <joanna> on node locked it should becuase it might have been freed up in the meantime
17:36:45 <vdrok> 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 <jroll> 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 <jlvillal> joanna: Can you also give an example of the error pecan is throwing using 423?
17:37:42 <jroll> and we would discuss the status code to replace 409 in the spec.
17:38:03 <lucasagomes> the problem of changing 409 is that old clients will not retry on the new return code
17:38:10 <joanna> it ended up with 'we have to do a research'
17:38:20 <jroll> 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 <lucasagomes> joanna, that's why I was thinking whether continue to use 409 + a header would be better
17:38:50 <joanna> we might use the prerequisite not ready + retry
17:38:58 <lucasagomes> 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 <rloo> jroll: so i think we need a spec and we can move this discussion to that spec
17:39:09 <joanna> when the node is locked, and 409 for conflicts + no retry
17:39:19 <vdrok> I like the header idea too
17:39:36 <jlvillal> jroll: Well it is valid in this other RFC...  https://tools.ietf.org/html/rfc2518   But point taken.
17:40:00 <joanna> lucasagomes: then all conflicts that will fail by definition would create unnecessary traffic
17:40:16 <jroll> jlvillal: which is an http extension for distributed authoring, dunno if it applies here
17:40:28 <joanna> also...
17:40:58 <joanna> I don't think that using 204 code as a POST response is valid
17:41:25 <joanna> would you all be fine with me preparing a spec about tidying up the responses?
17:41:57 <lucasagomes> joanna, that would be another problem, kinda off topic
17:42:03 <lucasagomes> joanna, but I'm good with the spec yeah
17:42:07 <vdrok> hm ,why? 204 just means that there is no content in response
17:42:07 <jroll> yeah, I'd prefer to solve the locking thing
17:42:19 <jroll> not really interested in debating semantics of 200 vs 204 for post requests
17:42:21 <joanna> it's sort of off topic, but the spec could be more generic the
17:42:24 <joanna> then*
17:42:39 <joanna> 204 is not a response for POST
17:42:46 <joanna> 201 created should be sent
17:43:10 <lucasagomes> 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 <lucasagomes> you can fix the return codes in parallel, I think we should have a separated spec for the locking
17:43:33 <lucasagomes> but it's up to you
17:43:49 <rloo> fixing/changing the return codes will require, at minimum, and RFE
17:43:51 <milan> lucasagomes, +1 less bikeshedding
17:44:01 <rloo> s/and/an/
17:44:07 <joanna> lucasagomes, thanks it is a good advice! :)
17:44:39 <joanna> rloo - can I treat that bug as an RFE?
17:44:52 <joanna> (rename the name of the bug?)
17:45:01 <rloo> up to you, as long as it is clear what it is.
17:45:28 <rloo> joanna: or just create a new rfe and link/point the existing bug to it.
17:45:40 <rloo> joanna: i don't think we care that much. as long as it describes the problem, etc.
17:46:02 <joanna> OK, as it already needs rewriting, I think I'll create a new one and a link
17:46:07 <joanna> thanks, rloo
17:46:26 <jroll> cool, so we're good here?
17:46:38 <jroll> anything else for open discussion?
17:46:40 <joanna> yes, thanks all
17:46:49 <lucasagomes> joanna, thank YOU for fixing it :-)
17:47:14 <joanna> i haven't fixed it... yet ;)
17:47:25 <lucasagomes> for trying :D
17:47:31 <jroll> heh
17:47:38 <jroll> obligatory gl;hf :P
17:47:45 <jroll> thanks for a good meeting all :) see you back in channel
17:47:50 <vdrok> thanks!
17:47:54 <jroll> #endmeeting