17:00:13 <NobodyCam> #startmeeting ironic
17:00:15 <openstack> Meeting started Mon Apr 11 17:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:17 <NobodyCam> #chair jroll devananda
17:00:18 <openstack> The meeting name has been set to 'ironic'
17:00:19 <openstack> Current chairs: NobodyCam devananda jroll
17:00:21 <devananda> o/
17:00:22 <TheJulia> o/
17:00:22 <jroll> ohai
17:00:25 <cinerama> o/
17:00:25 <zhenguo_> o/
17:00:33 <NobodyCam> and of course as always our agenda can be found at:
17:00:33 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:43 <jroll> NobodyCam is running this meeting as I'm on a flaky connection :)
17:00:44 <NobodyCam> So with that who's here for the meeting?
17:00:48 <jroll> thanks for that
17:00:50 <rama_y__> <rama_y> o/
17:00:56 <jlvillal> o/ \o /o \o \o/
17:00:58 <alineb> o/
17:01:03 <rloo> hi
17:01:05 <NobodyCam> :)
17:01:14 <NobodyCam> #topic Announcements
17:01:30 <NobodyCam> wb rloo
17:01:35 <dtantsur> o/
17:01:39 <rloo> thx NobodyCam :)
17:01:53 <NobodyCam> summit is in just 19 days :) everyone ready?
17:02:03 <jlvillal> Uhhhh....sure
17:02:05 <sambetts> o/
17:02:06 <jroll> 14?
17:02:09 <devananda> sure?
17:02:17 <jroll> I know it starts on a monday :P
17:02:19 <JayF> o/
17:02:22 <jlvillal> Uh 13 days
17:02:26 * jlvillal less ready
17:02:29 <NobodyCam> doh
17:02:30 <devananda> also, yea, isn't it two weeks away?
17:02:45 <NobodyCam> ya I was off on my timing
17:02:54 <rloo> NobodyCam is looking forward to the end of the summit I think ;)
17:03:02 <NobodyCam> lol +++
17:03:04 <NobodyCam> :)
17:03:06 <jroll> heh
17:03:25 <NobodyCam> just one annouoncement from me:
17:03:30 <krtaylor> o/
17:03:32 <NobodyCam> I wanted to say a quick comment on sub-team status updates.
17:03:42 <NobodyCam> over the last several meetings I have seen no-update on many of the teams items. and then details added during the meetings.
17:03:49 <NobodyCam> please try and have any updates posted to the white board at least an hour before the
17:03:57 <NobodyCam> meeting so folks have time to review and formulate any questions.
17:04:00 <rpioso> o/
17:04:15 <dtantsur> NobodyCam+++
17:04:23 <NobodyCam> :)
17:04:42 <thiagop> o/
17:04:46 <NobodyCam> thats it from me anyone else have an annouoncement
17:05:17 <NobodyCam> if not we jump right into:
17:05:29 <NobodyCam> #topic Subteam status reports
17:05:41 <NobodyCam> as always details are on the white-board:
17:05:50 <NobodyCam> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:06:17 <NobodyCam> let give folks a few minutes to review
17:06:25 <davidlenwell> o/
17:06:43 <NobodyCam> lots of no-updates this time
17:06:58 <NobodyCam> jlvillal: any thing on nova
17:07:00 <NobodyCam> :)
17:07:19 <NobodyCam> krotscheck: betherly: anything for UI?
17:07:44 <betherly> NobodyCam: v1.1 has been released.
17:08:01 <devananda> betherly: \o/
17:08:03 <jroll> \o/
17:08:08 <NobodyCam> betherly: w00t
17:08:09 <betherly> addition and removal of nodes currently being worked on which potentially could even be ready for the summit
17:08:17 <dtantsur> awesome
17:08:48 <NobodyCam> betherly: I added to the etherpad :)
17:08:52 <betherly> depending on how that goes I might talk to jroll and the release people re how putting out another release would work but we will see what happens
17:09:05 <betherly> NobodyCam: thanks for doing that! sorry - been a slightly ridiculous day
17:09:15 <jroll> betherly: we can release master branch during this cycle at any time
17:09:17 <jroll> :)
17:09:30 <betherly> jroll: awesomeness
17:09:37 <betherly> no promises but i will do my best
17:10:21 <jroll> I see we need an ironic-lib release, I'll submit that now
17:10:25 <NobodyCam> jroll: looking at lintan's comment under oslo we'll need that for ironic-lib too
17:10:31 <NobodyCam> lol
17:10:33 <NobodyCam> ++
17:10:33 <jroll> :)
17:11:30 <NobodyCam> jroll: devananda: any eta on the Multiple compute host stuff I've been seeing some qurestions arounds that
17:11:57 <NobodyCam> eta == info (ie. general stuff)
17:12:20 <jroll> we need to hammer on the claims API stuff first, that's my top thing after networking stuff
17:12:25 <jroll> and then on to the nova side
17:12:38 <devananda> ditto - top thing after networking is done
17:12:49 <NobodyCam> ++ :)
17:13:01 <sambetts> looking forward to it
17:13:38 <NobodyCam> other question / comments on status reports?
17:13:41 <JayF> jroll: are there specs/code up already around that to review?
17:13:58 <dtantsur> there is something very wip...
17:13:58 <jroll> here's the ironic-lib release request https://review.openstack.org/#/c/304229/
17:14:15 <jroll> JayF: spec needs a major update, will be this week
17:14:42 <NobodyCam> jroll: worth adding that to the whiteboard section?
17:14:54 <jroll> NobodyCam: line 129
17:15:04 <jroll> :)
17:15:11 <NobodyCam> ++ :p blind here
17:15:32 <jroll> anything else on subteam stuff?
17:15:52 <NobodyCam> moving on!
17:16:08 <NobodyCam> # topic Discussion
17:16:15 <NobodyCam> Summit session plans
17:16:20 <NobodyCam> #link https://etherpad.openstack.org/p/ironic-newton-summit
17:16:22 <jlvillal> NobodyCam: added a space there
17:16:28 <NobodyCam> thats you jroll
17:16:31 <jlvillal> For the "# topic"
17:16:34 <jroll> #topic Summit session plans
17:16:36 <NobodyCam> doh
17:16:42 <NobodyCam> #topic Discussion
17:16:48 <NobodyCam> ty jlvillal
17:16:56 <jlvillal> Two topics go in, one comes out...
17:16:56 <jroll> #undo
17:16:57 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xb1bf510>
17:17:02 <jroll> I already got it NobodyCam :)
17:17:09 <jroll> so
17:17:16 <jroll> I've picked out 6 sessions so far
17:17:26 <jroll> we need four more, and have a list on the linked etherpad
17:18:00 <jlvillal> Is obvious session at bottom the six that are already decided?
17:18:12 <jroll> my thoughts currently are: live upgrade, DLM, snapshots, and "how can we be more effective" (assuming we can make actionable things there)
17:18:14 <jroll> yes
17:18:28 <jroll> software raid is also interesting to me
17:18:56 <rloo> what needs to be discussed wrt DLM?
17:19:00 <dtantsur> my top is DLM, soft-raid, upgrades
17:19:02 <jlvillal> Is boot from cinder/SAN/volume something worth a session? Or do we already know what we need?
17:19:02 <jroll> so, curious how folks feel about those, or if they have different opinions on which we should do
17:19:09 <NobodyCam> I would put a vote in for Live upgrades
17:19:13 <dtantsur> rloo, switching to DLM instead of our home-grown logs?
17:19:21 <jroll> jlvillal: TheJulia said it should be able to be worked out in the spec
17:19:26 <jlvillal> Okay
17:19:31 <rloo> dtantsur: i thought we had already decided to switch to dlm
17:19:35 <devananda> rather than just a wish-list of features, could we actually write out what sorts of outcomes we're looking for?
17:19:45 <jlvillal> Does tooz = DLM ?
17:19:51 <dtantsur> jlvillal, essentially yes
17:20:11 <JayF> I'm curious why we think we need a session for software raid
17:20:19 <JayF> is there any particular difficult problem there to overcome?
17:20:21 <dtantsur> rloo, if everyone agrees, than we don't need a session, just someone (maybe mkovacik and I) will actually write a spec
17:20:23 <jroll> devananda: re: sessions? we should, yes
17:20:29 <davidlenwell> is it a contentious topic ?
17:20:31 <devananda> jroll: yea, most of htese look like feature proposals
17:20:40 <devananda> dtantsur: I thought we had all agreed in Tokyo
17:20:45 <JayF> I think     Node anomaly detection and resolution (mariojv) +1 interested: haomeng,gabriel-bezerra, mat128
17:20:51 <JayF> could be rolled into the ops session already allocated
17:20:55 <dtantsur> devananda, I'm not sure, but ok :)
17:20:58 <jroll> +1, we already agreed in tokyo about dlm
17:21:10 <jroll> I assumed it was there because there's things to work out yet
17:21:12 <rloo> dtantsur: yeah, I thought we had agreed in Tokyo but that it wasn't a high priority and given the state of tooz at the time, we'd do it in Newton
17:21:22 <dtantsur> JayF, I remember someone quite opposed to software RAID, but dunno
17:21:34 <dtantsur> rloo, aha, so my memory failed me then :) thanks
17:21:38 <jroll> so if there isn't anything on DLM to discuss, I'll remove it
17:22:05 <dtantsur> jroll++ lets have a spec for it
17:22:10 <jroll> ya
17:22:19 <NobodyCam> it's not on the list but I've seen several question on multipath I/O support
17:22:28 <jroll> I don't think we need a whole session on "FSM error states" too
17:22:30 <dtantsur> also the inspector HA discussion will involve tooz/dlm
17:23:10 <dtantsur> NobodyCam, oh god yes.. but is it something we can do within ironic? other than passing a correct root device?
17:23:15 * dtantsur is clueless to be honest
17:23:29 <NobodyCam> worth a session?
17:24:00 <jroll> I don't know that it's worth a session
17:24:06 <NobodyCam> dtantsur: I'm in hte same boat as to how much we can support
17:24:13 <TheJulia> I think it is worth a short fast discussion
17:24:13 <jroll> given we've barely talked about it so far
17:24:22 <jroll> idk if folks have enough context for a session (I don't)
17:24:24 <TheJulia> I believe we have the experteise to grasp and understand it in ~30 minutes
17:25:02 <davidlenwell> sessions are a good way of filling in context for folks
17:25:06 <TheJulia> But, we could also go get a cup of coffee and work through it since it is really just fallback root device selection logic I think
17:25:33 <jroll> so I agree with some of the notes on the etherpad and have removed live upgrades and multi-compute things
17:25:35 <NobodyCam> maybe some kind of open discussion session... thou those can go sideways quickly
17:25:37 <TheJulia> I'm more than happy to drive such a discussion and context overload
17:25:47 <dtantsur> TheJulia++
17:25:50 <jroll> leaving us with four sessions to choose from for four slots
17:26:05 <jroll> so... I think we are done if people are okay with those four being on the schedule?
17:26:10 <jroll> specifically:
17:26:19 <jroll> live upgrades
17:26:29 <jroll> anomaly detection stuff
17:26:34 <jroll> snapshotting
17:26:38 <jroll> how can we be more ffective
17:26:42 <rloo> oh, why are we removing live upgrades?
17:26:44 <thiagop> +1
17:26:59 <jroll> rloo: no, those are the four left
17:27:00 <jlvillal> rloo: I think those are the ones that will get sessions.
17:27:00 <NobodyCam> is upgrade there?
17:27:16 <rloo> jroll: oh, i misunderstood. good that it is there :)
17:27:21 <jroll> ya :)
17:27:30 <NobodyCam> I'm good with those four :)
17:27:33 <jlvillal> I like them. More effective and live upgrades are both very interesting to me.
17:27:33 <NobodyCam> +1
17:27:44 <devananda> jroll: I'm not keen on snapshotting -- what's there to discuss?
17:27:47 <jlvillal> Though I realize being more effective is probably a difficult them to figure out...
17:27:48 * jroll waits about two more minutes for objections
17:27:56 <jroll> devananda: all the insanity about "cleaning the image"
17:27:56 <jlvillal> s/them/thing/
17:28:11 <devananda> jroll: how does Nova do that?
17:28:12 <jroll> devananda: "'reset/unconfigure' copied disk to reset the image, removing SSH host keys, removing persistent network MAC configuration, and removing user accounts etc."
17:28:22 <devananda> yea, uh, how does Nova do that?
17:28:37 <devananda> I don't see how that is different for Ironic
17:28:47 <devananda> what _is_ different is trying to clone that image across different hardware
17:28:48 <jroll> I feel like it doesn't, I'm unsure
17:28:50 <TheJulia> if instance_id != known_id
17:29:06 <TheJulia> basically cloudinit checks and rebuilds _stuffs_ if the instance_id does not match what it knows
17:29:11 <jroll> devananda: we heavily rely on cloud-init running
17:29:15 <jroll> orly
17:29:20 <jroll> interesting
17:29:27 <dtantsur> I'm -0 on snapshotting. I don't have a context just as well, and the proposer is not attending the summit
17:29:51 <dtantsur> I'd rather see us talk about multipath, if I had to choose
17:29:52 <devananda> dtantsur: oh
17:29:54 <jroll> yeah, that's fair too
17:29:54 <TheJulia> I like the idea of snapshooting, but "cleaning/resetting/reconfiguring" the image just seems... wrong to me
17:29:59 <devananda> if the proposer is not there, I am -1 on discussing it
17:30:15 <rloo> if the proposer were there, is snapshotting something we'd want in newton?
17:30:16 <dtantsur> I'm referring to line 54
17:30:28 <devananda> s/the proposer/someone capable of representing the design proposal/
17:30:34 <jroll> snapshotting is something I continue to hear requests for
17:30:41 <dtantsur> rloo, provided the amount of huge changes we plan on? I doubt
17:30:51 <devananda> dtantsur: huh. I did not write that
17:31:18 <jroll> devananda: right, haomeng was asking if you could run it :P
17:31:22 <jroll> anyway
17:31:39 <jroll> snapshotting is what's left, if folks would prefer something else, I'm good with that
17:32:03 <devananda> mat128: ohhai :)
17:32:05 <mat128> hey there, I'm late :(
17:32:08 <jroll> software raid, multipathing, FSM error states, others are all options
17:32:09 <NobodyCam> might be a good place to get context for mp io stuff
17:32:34 * TheJulia can handle context sharing if we have session
17:32:35 <dtantsur> jroll, of these - multipath. otherwise I'd talk about ansible driver, but we ruled it out
17:32:41 <sambetts> have we got a session for boot from volume ?
17:32:42 <krtaylor> I like the idea of an open topics session, allows for discussions that pop up during the week, as long as it is moderated
17:32:44 <NobodyCam> shold we (#) vote for te last session
17:32:58 <jroll> dtantsur: I'm also fine with ansible driver
17:33:04 <JayF> krtaylor: I generally like keeping those to hallway track, tbh
17:33:07 <devananda> jroll: ++ ansible driver session
17:33:11 <rloo> are there any cross-project initiatives that we need to discuss wrt ironic?
17:33:12 <jroll> dtantsur: thinking more about it, those folks are in the same shoes us agent people were in
17:33:32 <devananda> JayF, krtaylor: or friday's slot
17:33:43 <devananda> rloo: we have two of those already scheduled, I believe
17:33:44 <rloo> or a session where we go over/discuss eg 4? specs
17:33:57 <dtantsur> I'm also -0 on "how can we be more effective" FWIW. we can talk about it with beer later in the evening
17:34:02 <rloo> devananda: ok
17:34:10 <TheJulia> dtantsur: ++
17:34:19 <devananda> TheJulia: do you feel there's a need to have (another) session on cinder integration?
17:34:23 <rloo> dtantsur: wrt the effective, we could talk about it over beer, but i'm interested in what is slowing down reviewers, and what is slowing down developers
17:34:47 <dtantsur> rloo, great topic for beer! also, we had this kind of discussion numerous times...
17:34:51 <rloo> dtantsur: i could also start an email discussion.
17:35:02 <dtantsur> ++ for email discussion
17:35:04 <jroll> I think it's good to revisit sometimes
17:35:12 <rloo> we've had discussions between various people. i am hoping for guidelines or some consensus
17:35:12 * thiagop thinks that beer is better than e-mail :)
17:35:19 <jroll> also keep in mind there's some people that don't go out at night
17:35:31 <jroll> or might be more apt to speak up during a session
17:35:41 <rloo> also, it is hard to have a big group participating in one discussion over beer
17:35:42 <jroll> I'm +1 on a "real" session for it
17:35:47 <jroll> yep
17:35:49 <dtantsur> jroll, of what I know about people, they tend to speak more with beer
17:35:50 <JayF> Yeah, I mean, honestly, if I think it's something we need to officially chat about (like efficiency as a team), I'm -1 about just trusting "over beer" for it
17:36:01 <JayF> as I think that will lend to the same voices getting heard as usual
17:36:02 <jroll> dtantsur: some do, some do not
17:36:12 <rloo> maybe we need the beer session before the actual session :)
17:36:14 <dtantsur> "if I think it's something we need to officially chat about" I don't
17:36:14 * NobodyCam notes that there are a couple things still up in the Open discussion section
17:36:16 <jroll> some do not feel comfortable in a drinking environment
17:36:36 <jroll> NobodyCam: yep, and I'm at 8% battery
17:36:37 <TheJulia> devananda: wrt cinder, I really don't think so since in some ways we would just be emulating things already done :)
17:37:04 <mat128> about cloning/snapshotting, just read that haomeng won't be at the summit and I can't go either, wanna use that session for efficienty as a team in a more formal context?
17:37:24 <jroll> so I've locked in live upgrades and anomaly detection
17:37:25 <dtantsur> so my vote for the final 4 sessions: multipath, live upgrades, ansible driver, anomaly detection (in this order)
17:37:47 <TheJulia> JayF: agree with that point, although I fear we will just bikeshed on how we can do better
17:37:50 <jroll> and I'm thinking effectiveness and ansible for the other two
17:37:58 <jroll> but let's come back to that tomorrow in irc or ML
17:38:29 <devananda> TheJulia: cool, that was my impression
17:38:32 <JayF> I really think anomoly detection can go into the ops session I'm already running
17:38:38 <rloo> jroll: sorry, come back to what tomorrow?
17:38:42 <JayF> unless there's a subtext there I'm missing?
17:38:42 <devananda> jroll: 3rd party CI status?
17:38:48 <NobodyCam> so move on to Open discussion
17:38:55 <jroll> rloo: the last two selections
17:39:02 <NobodyCam> oh 3rd party ci is a good topic
17:39:03 <devananda> jroll: oh, i see that's under the Gate topic
17:39:04 <jroll> devananda: sure, maybe
17:39:13 <krtaylor> isnt that in the QA session?
17:39:14 <gabriel-bezerra> any reference on multipath?
17:39:17 <devananda> would that be worth its own session, if we can get thingee to join us?
17:39:19 <rloo> jroll: ah. ok, but not irc. ML. that'll give people who aren't present, a chance to voice their opinion.
17:39:23 <devananda> krtaylor: oh, is it?
17:39:25 <gabriel-bezerra> I'd like to understand it better
17:39:29 <dtantsur> yeah, it's good, but we probably don't need to spend the whole session
17:39:44 <jroll> devananda: possibly. not sure. I don't like all the new sessions being proposed at the last minute :/
17:39:50 <krtaylor> devananda, yes, sorry, labeled gate session
17:39:52 <NobodyCam> like to move on in one minute
17:39:53 <dtantsur> we have a pretty good plan for 3rd party CI, we just have to make sure people are on track and don't have blockers
17:39:57 <jroll> we need these locked in by friday
17:40:15 <jroll> NobodyCam: ++ let's move on and I'll take this to the ML
17:40:22 <NobodyCam> ++
17:40:26 <NobodyCam> #topic Open discussion
17:40:31 <NobodyCam> we have a couple items here:
17:40:37 <NobodyCam> zhenguo_: that you
17:40:42 <NobodyCam> thats*
17:40:43 <zhenguo_> hi
17:40:51 <JayF> I have an extra item for open discussion, if we end up having time.
17:40:55 <zhenguo_> I would like to discuss about the serial console stuff
17:40:58 <krtaylor> dtantsur, I can summarize where we are at in the gate session
17:41:13 <dtantsur> krtaylor, awesome
17:41:28 <NobodyCam> zhenguo_: is there a review we can link to this
17:41:49 <zhenguo_> yeahhttps://review.openstack.org/#/c/300582/
17:42:01 <NobodyCam> #link https://review.openstack.org/#/c/300582
17:42:33 <zhenguo_> we have two options : one is add a custom HTTP proxy on nove side to leverage the shellinabox console
17:42:47 <zhenguo_> another one is add a new console driver to replace shellinabox
17:42:54 <jroll> my battery is gone, so I need to bounce, but IMO I'd rather not add a new proxy to nova, consistency for users is key
17:43:05 <jroll> I invited mriedem here to join this discussion as he has similar feelings, I suspect
17:43:07 <vdrok> another thing that might be relevant - one of our guys has a wip patch with vnc console - https://review.openstack.org/296437
17:43:10 <devananda> jroll: ++
17:43:20 <NobodyCam> jroll: ++ and ack
17:43:32 <jroll> but alas I need to go, thanks for the good meeting y'all, thanks NobodyCam for running things
17:43:36 <jroll> see y'all tonight/tomorrow
17:43:36 <mriedem> i'd prefer not adding a new console proxy in nova, yes
17:43:38 <TheJulia> I guess the question I would have w/r/t shellinabox is what was the reason it as chosen originally
17:43:50 * TheJulia just lacks that context
17:43:55 <devananda> TheJulia: we inherited it from the old nova-baremetal driver
17:43:59 <devananda> and, fwiw, it worked in Nova back then
17:44:06 <zhenguo_> mriedem: but I think it's may also benefit for other drivers' web based console
17:44:06 <sambetts> I personally liked the socat implementation for serial cli console
17:44:07 <devananda> ~ Folsom era
17:44:23 <mat128> vdrok's review is super interesting
17:44:33 <TheJulia> So sounds like we just ned to move on and be in sync with what nova is doing now :\
17:44:37 <TheJulia> s/ned/need/
17:44:40 <devananda> we haven't had CI testing of it, though, and I am unaware of what may or may not have changed on the Nova side that caused our shellinabox console driver to stop working
17:44:40 <mat128> AFAIK not all aten provide a native VNC like that (supermicro doesnt)
17:44:50 <devananda> TheJulia: exactly
17:45:06 <vdrok> mat128: not actually mine :) IIRC I was said it's tested on supermicro
17:46:26 <NobodyCam> I don't have the context to weigh in on console stuff as it impacts nova
17:46:55 <NobodyCam> but I can see that work requiring a spec
17:46:59 <mat128> We have graphical console stuff running and the only nova change is start console / get console stuff
17:47:02 <mat128> no proxy
17:47:18 <NobodyCam> mat128: ++ can you link the review
17:47:24 <mat128> https://bugs.launchpad.net/ironic/+bug/1567629
17:47:26 <openstack> Launchpad bug 1567629 in Ironic "[RFE] Nova graphical console support" [Undecided,New] - Assigned to Mathieu Mitchell (mat128)
17:47:26 <devananda> mriedem: nova uses novnc as a proxy to the hypervisor's console implementation, right?
17:47:28 <mat128> drafting up the spec unfortunately
17:47:36 <mat128> devananda: thats correct
17:47:56 <zhenguo_> devananda: nova have some different console proxy
17:48:05 <mat128> we end up running a `display driver` in a docker container
17:48:09 <mat128> essentially IPMIview + x11vnc
17:48:27 <devananda> mat128: interesting RFE
17:49:00 <tiendc> Hi everyone, I also proposed a spec for this serial console stuff
17:49:06 <tiendc> Here is my spec https://review.openstack.org/#/c/296869/
17:49:09 <TheJulia> very interesting since it would help users run things that don't have a serial port console
17:49:17 <tiendc> I propose to add an IPMI proxy (ironic-ipmiproxy) to help connect Nova-serialproxy and bare metals
17:49:18 <JayF> Heh maybe console needs a design summit session, lol
17:49:18 <mat128> I guess such "display driver container" could do the transformation between ipmitool console and a nova-compatible console
17:49:25 <mat128> relieving ironic-conductor of such duties
17:49:32 <dtantsur> JayF, lol, it looks so
17:49:35 <TheJulia> JayF: yeah...
17:49:48 <NobodyCam> can we add all the reviews to the agenda and keep it there until next week giving folks time to review
17:49:50 <mat128> < not at the summit :(
17:50:03 <mat128> but wont prevent anyone from having the discussions :P
17:50:14 <NobodyCam> I'd like to make sure we have time for vdrok's Node name updates topic
17:50:19 <mat128> NobodyCam: good idea, will make sure I finish my spec
17:50:20 <zhenguo_> NobodyCam: agree
17:50:20 <devananda> actually, this looks like a good summit session IMO
17:50:22 <TheJulia> mat128: when will your specification be available?
17:50:36 <mat128> this week for sure
17:50:40 <TheJulia> awesome!
17:50:44 <devananda> because we have several different proposals, and we also need to understand how Nova is currently expecting to interact with the functionalty
17:50:44 <mat128> just have to finalize both specs
17:50:58 <mat128> we're essentially already running this, so it's more describing than solving new issues
17:51:06 <NobodyCam> devananda: that too! can you address in the ML thread
17:51:08 <rloo> +1 on summit session for serial console
17:51:11 <sambetts> This is another console related proposal, https://review.openstack.org/#/c/293871/
17:51:13 <dtantsur> ++
17:51:17 <TheJulia> ++
17:51:31 <rloo> at least it is clear that folks want this feature :)
17:51:37 <NobodyCam> yes!
17:51:39 <devananda> mat128: from a quick read of your RFE, it looks like it is very specific ot your ipmlmentation and would need to be abstracted somewhat
17:51:49 <jlvillal> jroll leaves for 10 minutes and look what happens to his summit schedule ;)
17:51:57 <NobodyCam> lol
17:51:59 <devananda> yea, clearly a feature a lot of folks want :)
17:52:01 <thiagop> lol
17:52:13 <NobodyCam> we will have a ML thread so he can catch up
17:52:15 * thiagop watches clock
17:52:16 <devananda> I, for one, do not yet understand the differences between these proposals
17:52:21 <devananda> and would like to
17:52:24 <devananda> (but not right now)
17:52:29 <mat128> agreed
17:52:36 <NobodyCam> lets more on to Node name updates !
17:52:42 <NobodyCam> vdrok: thats you
17:52:46 <vdrok> #link https://review.openstack.org/300983
17:53:02 <vdrok> here is the patch, there are 2 bug resolved
17:53:28 <vdrok> first one being - forbid node name removal if api version is < 1.5 where names were introduced
17:53:42 <vdrok> this changes return code 200 to 406
17:54:25 <dtantsur> I've put -1 on that patch as it looks like an API break to me..
17:54:25 <vdrok> second one being checking the final name that is requested in PATCH so that it is not impossible to do ironic node-update node add name=abc name=&*^&*^
17:54:40 <vdrok> that changes 200 to 400 in this case
17:54:57 <vdrok> yep, there also is a today's thread about it
17:55:19 <vdrok> on the one hand it is api break, on the other - both are bugs that should be fixed I think
17:55:37 <devananda> I was reviewing that just before the meeting ...
17:56:12 <mat128> vdrok: why do we have to absolutely prevent an operator from setting a name using the old version?
17:56:15 <devananda> IMO, first one is clearly a fix and is OK to land without API bump. second one is less clear to me.
17:56:31 <mat128> just questioning the requirement, since it makes a 2xx become a 4xx
17:56:56 <devananda> mat128: the node name isn't included in the response body to a GET request for api v < 1.5
17:56:56 <vdrok> mat128: that's why we added api microversions in the first place :)
17:57:12 <dtantsur> devananda, for me it's the opposite. removing ability of removing the node name has much higher chances of breaking people
17:57:13 <devananda> mat128: a request to add or change the name will be rejected, but a request to remove the name gets accepted
17:57:17 <mat128> devananda: thats perfect since it wont break old clients
17:57:25 <thiagop> shouldn't the second one be for any duplicated parameter on update?
17:57:27 <NobodyCam> i think a review of how we hide / remove thing from privious api versions would good in general
17:57:37 <mat128> vdrok: it's just a new feature, hidden from old clients. In some specific way, you can push a name update on the old API, but you really have to know how
17:57:43 <vdrok> devananda: you mean doing 2 subsequent name updates and checking only the last one?
17:58:03 <devananda> vdrok: sorry, I was referring to the first issue (old client can remove /name)
17:58:08 <NobodyCam> *FYI: two(2) minutes t go*
17:58:08 <vdrok> mat128: currently you can only remove name with old api version
17:58:19 <vdrok> devananda: ah, gotcha
17:58:21 <TheJulia> NobodyCam: ++ since it seems like we should be moving forward, IMO
17:59:11 <dtantsur> lets continue on the ML?
17:59:11 <vdrok> so yeah, removing name with old api version is not a huge problem, and can be left as is I think
17:59:30 <NobodyCam> can we take this one to the main ironic channel as we now have < 1 minute left
17:59:48 <mat128> you mean 302 right? :)
18:00:04 <NobodyCam> dtantsur: ++
18:00:12 <NobodyCam> thats time
18:00:13 <jlvillal> time is up :(
18:00:18 <NobodyCam> Thank you all
18:00:25 <vdrok> thanks
18:00:35 <NobodyCam> lets take anything else back to main chanel
18:00:37 <sambetts> thanks :)
18:00:40 <NobodyCam> #endmeeting