18:00:45 <jroll> #startmeeting ironic-v2-api
18:00:45 <openstack> Meeting started Tue Aug  9 18:00:45 2016 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:48 <openstack> The meeting name has been set to 'ironic_v2_api'
18:00:49 <jroll> who's around? devananda ?
18:00:59 <cdent> o/
18:01:10 <rpioso> \o
18:01:28 <jroll> ohai cdent !
18:01:35 <mat128> o/
18:01:41 <cdent> ahoy hoy
18:01:43 * jroll waits a couple minutes
18:02:53 <cdent> since I've missed the other meetings I went through the etherpad@ https://etherpad.openstack.org/p/ironic-v2-api and added some (brief) comments
18:03:02 <jroll> yeah, I saw those, thank you
18:03:31 <jroll> okay let's get into it
18:03:35 <jroll> #topic discussion
18:03:52 <jroll> so as cdent mentioned, etherpad is here:
18:03:54 <jroll> #link https://etherpad.openstack.org/p/ironic-v2-api
18:04:01 <jroll> a couple things I've noticed
18:04:14 <jroll> 1) seems like we can do this all incrementally on v1
18:04:22 <jroll> 2) we agree on most/all of the things
18:04:45 <cdent> yeah, I kinda wondered "where's the v2 part?"
18:04:51 <jroll> :)
18:05:08 <jroll> I made the meeting thing, the pad, etc before we started thinking about that
18:05:08 <mat128> that's actually good news, IMO :)
18:05:33 <mat128> this v2 effort can be turned into an "adressing v1 problems"
18:05:37 <jroll> that bit does make me want to spin up a cross-project session on "how do projects bump the minimum" in barcelona
18:05:52 <jroll> because we'll need to do that eventually, given the goal is to kill some cruft and bad APIs
18:06:29 <rloo> jroll: ++ for crossproject
18:06:31 * jroll still has a todo to kick off a ML thread about that
18:06:50 <cdent> there's quite a bit of that buried in alaski's microversions thread
18:07:02 <cdent> (not solutions, same concern)
18:07:03 <mat128> jroll: by "bump the minimum", do you mean moving projects that use us to newer api versions?
18:07:14 <jroll> cdent: yeah
18:07:29 <jroll> mat128: making the minimum usable version higher, while breaking users as little as possible
18:08:02 <jroll> and keep in mind not everyone uses ironicclient, I'm thinking of the random bash/python/node scripts that were written two years ago and are in prod at some little deployment we've never heard of
18:08:13 <jroll> some people don't even know about microversions!
18:08:39 <cdent> and why would they, they're a local invention
18:08:43 <mat128> on that topic, I know we have our own php client, pinned to some old microversion
18:08:52 <jroll> cdent: I still just want to call them versions
18:09:08 <jroll> and get rid of the 1. (or 2. in nova)
18:09:31 <mat128> 1.24 or 24 is just the same, isn't it?
18:09:40 <jroll> assuming we never have a 2.0, yes :)
18:09:43 <cdent> pretty much how it has turned out, yea
18:09:54 <mat128> we could decide in next cycle that minimum is 1.xx and anything less gets a deprecation warning
18:09:57 <rloo> but i don't think we can assume that we will never have a 2.0
18:10:15 <jroll> mat128: well that's the hard bit, right? where do you put that warning such that a curl user always sees it
18:10:29 <jroll> which is the c-p part to solve, we should all do that the same
18:10:43 <mat128> given how we have never defined how the deprecation warning will appear, there's no easy answer
18:10:59 <mat128> I *think* communicating it via release notes, along with warning in ir-api logs is sufficient
18:11:06 <mat128> and give 1 release before you delete it completely
18:11:17 <mat128> (or 1 cycle, follow openstack guideline here)
18:11:30 <jroll> I'd disagree, someone with a working client likely won't read the release notes and likely won't have log access
18:11:34 <jroll> anyway, I plan to push on how to do that in a cross-project context, while we work inside ironic on fixing things
18:11:53 <mat128> jroll: the only way to notify that person is to break that contract
18:11:59 <rloo> mat128: so what you are suggesting, is what the crossproject discussion is about. whatever process is decided, ought to be similar across projects if the projects opt into it
18:12:01 <mat128> unless you think putting a header in the response
18:12:10 <cdent> jroll you're probably going to want to advertise the c-p session pretty heavy as a lot of people care but probably aren't paying close attention
18:12:15 <mat128> rloo: are we really the first project to deprecate stuff in our api?
18:12:25 <jroll> mat128: yep
18:12:25 <rloo> mat128: dunno.
18:12:29 <jroll> cdent: yep.
18:12:38 <cdent> mat128: nova is having the same problem with deprecation of nova-net right now
18:12:53 <cdent> and how to "signal" that (which I think is a horrible term)
18:13:14 <mat128> I remember seeing keystone deprecation warnings somewhere
18:13:19 <mat128> maybe in their CLI?
18:13:32 <jroll> right, that's for v2 -> v3
18:13:39 <jroll> and they've been working on that for years
18:13:45 <mat128> but it could be the same for 14 -> 15
18:13:47 <jroll> and there's still a cycle or two left to go before dropping it
18:13:54 <mat128> hmm
18:14:07 <jroll> I don't want to shout for years that we're dropping some inconsequential version :)
18:14:15 <mat128> ok so given the current state of things
18:14:29 <cdent> precedence and precedents are a pita
18:14:41 <jroll> heh
18:14:43 <mat128> a) we are not alone in this situation, b) there's no precedent of a project succeeding in deprecating a part of their API, c) microversions don't help because you can't drop earlier versions
18:14:58 <mat128> I think a cross project effort is worth it then
18:15:08 <mat128> and whatever we choose there should apply to all of us
18:15:24 <jroll> yep :)
18:15:25 <mat128> (no, I'm not opening that 'following guidelines' debate)
18:15:26 <mat128> ;)
18:15:45 <mat128> so
18:15:51 <mat128> can we (this 'v2' taskforce)
18:16:00 <mat128> focus on improving v1 without deprecating/killing anything old we have?
18:16:11 <mat128> given how that part is "blocked" by the c-p effort?
18:16:23 <jroll> yeah, I think we can
18:16:35 <jroll> the earlier we have the higher versions in a better place, the earlier we can kill the lower
18:16:43 <mat128> yup
18:16:54 <jroll> let's work to improve 1.latest inside ironic, while we work cross-project to get rid of 1.1
18:17:07 <jroll> or to figure out how to get rid of 1.1, anyway
18:17:13 <mat128> #agreed <jroll>	 let's work to improve 1.latest inside ironic, while we work cross-project to get rid of 1.1
18:17:17 <mat128> =)
18:17:27 <jroll> you might need to be chair for that, idk
18:17:32 <jroll> #agreed let's work to improve 1.latest inside ironic, while we work cross-project to get rid of 1.1
18:17:35 <mat128> bah
18:17:42 <mat128> I don't think we've heard everyone though
18:18:06 <cdent> great idea
18:18:08 <jroll> does anyone disagree?
18:18:13 <cdent> also very pragmatic
18:18:21 <jroll> rloo and rpioso are the only ones left :)
18:18:39 <rloo> i didn't disagree :)
18:18:52 <jroll> just making sure you're still with us :P
18:19:02 <rloo> ha ha
18:19:23 <jroll> okay, I think we're all good with that
18:19:25 <rpioso> agree
18:19:44 <jroll> woo
18:20:05 <jroll> so going back to ironic
18:20:20 <jroll> the pad is starting to get into the 'how', not the 'what'
18:20:47 <jroll> so I think we should capture the 'what' in a spec before it gets too messy, and then start focusing on the 'how'
18:21:25 <jroll> and put it in the backlog, and continue to iterate on it after that lands
18:21:34 <jroll> does anyone want to volunteer to own proposing and keeping up with that?
18:22:01 <mat128> jroll: I thought devananda wanted to submit the spec and created that etherpad only for sharing his draft
18:22:23 <rloo> ++ that's what deva mentioned in yesterday's weekly meeting
18:22:30 <jroll> ah okay, perfect
18:22:38 <jroll> wasn't sure how much he had volunteered for :)
18:22:41 <rloo> let's make it official then with a #whatever :)
18:22:44 <jroll> so I'll bug him to do that
18:23:04 <jroll> #agreed volunteer devananda to propose the problem bits of a spec to the backlog
18:23:24 <rloo> might not even be backlog...
18:23:51 <jroll> idk, an unfinished spec belongs there imo
18:23:59 <jroll> but that isn't a super strong opinion, so :)
18:24:07 <jroll> as long as it's in the repo, I'm happy
18:24:15 <rloo> oh, backlog has always been somewhat questionable for me anyway.
18:24:49 <jroll> heh
18:25:08 <jroll> I wonder if each problem should be a separate spec
18:25:22 <jroll> so we can limit specs to a single change
18:25:57 <mat128> ^not a bad idea
18:26:23 <cdent> seems like that would increase the chance of stuff getting one
18:26:25 <cdent> done
18:26:27 <jroll> I feel like the next step is start working out solutions one-by-one, so a spec each would make that easier
18:26:31 <rloo> jroll: that is another way to approach it. if each one is implemented via a bump in microversion then that makes sense. if we were going to do a real /v2/ then they should all be together.
18:26:50 <jroll> otherwise a spec with a huge number of changes will never end the bikeshedding
18:26:56 <mat128> rloo: I feel like it's going to be the former
18:27:13 <jroll> rloo: sure, agree, I also question if a big v2 drop would ever get done :)
18:27:21 <jroll> similar reasoning
18:27:57 <rloo> this is reminding me of the new states spec that was a parent spec ...
18:28:03 <jroll> I say we try to do it incrementally until we find out it's impossible
18:28:18 <mat128> +1
18:28:31 <jroll> rloo: was it? did we find that easier or harder?
18:28:40 * jroll honestly can't remember, other than that whole thing was painful
18:29:19 <rloo> i think it was good to have the overal viewpoint, but we realized that we weren't going to implement it all in one shot, and for bikeshedding or other reasons, didn't want to drill down into more detail for each state, in that original spec.
18:30:03 <mat128> I think the question to ask ourselves is the following: "Does each part bring business value (ugh) independently?"
18:30:08 <rloo> it was painful cuz we didn't spend enough time thinking about it and the process to get it done and it involved microversions etc.
18:31:19 <jroll> yeah, fair
18:31:25 <jroll> it kind of kick-started the microversion thing
18:31:43 <rloo> yup. i think that was the bigger mess.
18:31:48 <jroll> indeed
18:31:54 <mat128> good thing it's in place already :D
18:32:01 <jroll> obligatory i-have-no-idea-what-im-doing.gif
18:32:05 <rloo> mat128: sort of. mostly...
18:32:23 <rloo> we don't do portmortems, do we :)
18:32:36 <jroll> no. we should.
18:34:00 * jroll made a note
18:34:54 <jroll> so, let's try the one-spec-for-each thing and see how that goes
18:35:00 <jroll> I really don't think one big spec would ever merge
18:35:19 <mat128> but it'd be a starting point for splitting
18:35:45 <jroll> mmm, we could do problem description as one big one
18:35:53 <jroll> and break them out as we flesh it out more
18:35:55 <jroll> hrm
18:36:02 <rloo> see what deva thinks since he offered to put up a spec
18:36:06 <jroll> yeah
18:36:14 <jroll> okay, I'll do that
18:36:23 <rpioso> seems like the overall viewpoint for this effort would have value
18:36:48 <jroll> once we get that part landed we can start working on how to fix each thing
18:36:54 <jroll> rpioso: what do you mean by viewpoint?
18:37:22 <rpioso> guiding principles
18:38:05 <jroll> as... "an API should be simple to use" (for some definition of simple)?
18:38:06 <rpioso> such as incremental improvement to v1, instead of a new, shiny, yet never delivered, v2
18:38:08 <jroll> things like that?
18:38:10 <jroll> yeah
18:40:19 <jroll> okay, so we're on the tail end of newton, I suspect most of us will be pretty busy. do we want to try to get that spec(s) merged in the next two weeks and skip next week's meeting?
18:40:37 <jroll> or keep next week's meeting in case something comes up we want to talk about here
18:40:58 <mat128> I would keep it
18:41:03 <mat128> just to make sure we made progress on the spec
18:41:10 <mat128> or got it approved / merged / looked at by the right people
18:41:23 <jroll> alright, I'm okay with that
18:42:07 <jroll> #topic open discussion
18:42:13 <jroll> anything else folks want to chat about here?
18:42:44 <cdent> nosir
18:43:05 <rloo> zilch
18:43:05 <mat128> nope I think that's it :)
18:43:07 <jroll> alright, thanks for coming y'all :)
18:43:10 <jroll> #endmeeting