18:00:38 <jroll> #startmeeting ironic-v2-api
18:00:40 <openstack> Meeting started Tue Jul 26 18:00:38 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:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:43 <openstack> The meeting name has been set to 'ironic_v2_api'
18:00:45 <jroll> anyone around?
18:00:53 <jroll> should be a short one
18:01:08 <rpioso> o/
18:02:43 <jroll> hey rpioso
18:02:51 <rpioso> hi jroll
18:03:15 * jroll waits a few minutes to see if others are around, and pings the channel
18:03:35 <JayF> o/
18:05:40 <jroll> ok, quite the crowd :D
18:05:46 <jroll> #topic announcements / reminders
18:05:51 <jroll> I have nothing, anyone else/
18:05:54 <jroll> ?
18:06:25 <jroll> so I was supposed to do a formal writeup of problems with the existing API, but I didn't get around to that
18:06:29 <jroll> I should have it for the next meeting
18:06:53 <jroll> also, the nova folks at the midcycle last week wanted to hear more about this work
18:07:03 <jroll> we kind of went through some of the things we were intending to solve
18:07:31 <jroll> they asked why we couldn't just do all of this in the v1 api via microversions, and eventually raise the minimum
18:07:50 <jroll> which seems functionally equivalent, as far as versioning and dropping things goes
18:08:09 <jroll> the catch is if we want to change frameworks, if that will necessitate a v2 - I'm not sure it does
18:08:20 <jroll> so that's one thing to think about while we work on this
18:08:43 <jroll> if we can do it all in a v1 context without making life too hard, that would be nice
18:08:55 * devananda sneaks in the room, late
18:09:28 <jroll> one other thing: they noted that while an all in one "deploy" endpoint would be nice for users, they're considering parallelizing bits of spawn() (e.g. volumes, networking, image downloads, etc)
18:09:41 <jroll> so we definitely want to still be able to do single pieces at a time
18:09:43 <jroll> devananda: welcome :)
18:10:14 <devananda> jroll: good summary so far :)
18:10:20 <rpioso> jroll: perhaps v1 APIs could be adapted to a new v2 framework
18:10:22 <rloo> isn't one of the reasons we want a v2, is to delete some of the existing v1 API?
18:10:42 <jroll> rloo: right, which we can effectively do by raising the minimum microversion
18:10:49 <rloo> or can we delete some apis with a microversion.
18:10:56 <jroll> rpioso: yeah, that's what I'm thinking :)
18:11:14 <jroll> rloo: we can, but that doesn't help eliminate the code or needing to think about those APIs
18:11:45 <rloo> so that'd be why we want a v2.
18:12:04 * rloo doesn't want to think about v1 API if we have a newer API.
18:12:30 <devananda> rloo: we won't be able to remove the v1 api for a while, even if we add a v2
18:12:42 <jroll> well, so that's the thing - if we do these changes in the v1 API, and then eventually raise the minimum to 1.50 (for example), it's effectively the same, right?
18:13:26 <devananda> jroll: I'm not sure it is
18:13:43 <rloo> we should think of it from the user's point of view and what v1, v2 means.
18:13:55 <rloo> seems like something to ask the api folks.
18:14:01 <jroll> devananda: assuming 1.50 is where we drop the cruft?
18:14:09 <rloo> i mean, as developers, we can do *anything* :)
18:14:35 <devananda> rloo: we're magical like that ;)
18:14:38 <jroll> rloo: indeed, cdent wanted to help with this (and brought up some of this last week), but is traveling today
18:14:49 <devananda> if we were to build a v2 api in parallel, with a new framework, etc, the development process would be quite different, I think
18:15:05 <devananda> than if we incrementally add & remove features from v1 using microversions
18:15:14 <jroll> sure
18:15:26 <rloo> whatever we do, i don't think we want to incrementally add/remove features?
18:15:43 <devananda> rloo: that was, essentially, what hte nova team suggested
18:15:49 <rloo> i mean, we want the new shiny whatever available. all available.
18:15:51 <devananda> to incrementally evolve the v1 API to the point we want it
18:16:02 <devananda> then drop backwards compat support by bumping hte minimum version
18:16:05 <jroll> devananda: one of my fears with that model is, waiting to land the v2 api until everything is 'perfect' (read: never)
18:16:36 <rloo> i don't like the incremental evolution. it partially depends on the end/new API though.
18:16:37 <jroll> otoh, we won't have merge conflicts and such
18:17:03 <jroll> rloo: what don't you like about it?
18:17:05 <rloo> would it make sense to propose what the new API would look like, then see whether it makes (better) sense as v1 or v2?
18:17:28 <rloo> jroll: if the api 'model' is different from the existing model, then having both as v1 is confusing to the user.
18:17:42 <jroll> got it
18:17:46 <rloo> jroll: eg, it would be like having the ironic CLI and OSC plugin being 'the same' based on some versioning.
18:17:46 <devananda> jroll: while I share that concern, I also see the flip side: having a separate API would allow us (devs) to build it without impacting the current API (dealing with merge conflicts, adding a lot of backwards-compat code, etc) and allow deployers to run both
18:18:02 <jroll> rloo: yes, that would make sense, and I think that's what I'm proposing. I don't want to make a decision yet, but it's something to consider
18:18:14 <devananda> jroll: that has downsides too -- look at keystone for an example where folks have, after years, still not widely deployed keystone v3 API
18:18:21 <jroll> just wanted to summarize the discussion here
18:18:23 <jroll> devananda: indeed
18:19:00 <jroll> it'll take some thought, and I think we need to define what the new API semantics look like, and probably play with code both ways, before we can make a decision
18:19:01 <devananda> I'm not currently advocating for anything specific, justbrainstorming the pros and cons of each
18:19:11 <jroll> yeah
18:19:13 <jroll> ++
18:19:18 <devananda> having a clearer idea of what end goal we want to reach will help
18:19:24 <rloo> ++
18:19:46 <devananda> if it's radically different from the current API (I think it will be), we should do the exercise of planning out how to incrementally get there
18:20:27 <jroll> yep, agree
18:21:37 <jroll> I'm going to move to open discussion since we're not really on a topic anyway
18:21:40 <jroll> #topic open discussion
18:21:53 <jroll> anything else on that topic? or other things folks want to talk about?
18:22:40 <devananda> sure, i've got a question
18:23:16 <devananda> since we're talking about a plan that hinges on being able to raise hte min API version, I'd like to ask ya'll -- when do you feel that will be warranted / OK ?
18:23:40 <devananda> I don't think anyone has yet laid out the circumstances in which we'll ever raise that, or how we'll handle it
18:23:47 <jroll> that's a great question, and I think I'd want to see a mapping of cycle:version to answer it well
18:24:11 <jroll> but I don't think it's crazy to give a couple cycles of deprecation and do it
18:24:17 <devananda> historical cycle to max version?
18:24:21 <jroll> but only for a really good reason
18:24:23 <jroll> yeah
18:24:28 <devananda> "deprecation" -- what's that look like for an API rev ?
18:24:36 <jroll> that's a completely different question :)
18:24:45 <devananda> I don't think we *can* deprecate an API version
18:24:50 <jroll> (I don't have a good answer for that right now)
18:25:02 <devananda> a given version of the server either supports API vX.YY or it does not
18:25:38 <rloo> doesn't 'deprecation' mean it is supported but a warning is issued to say use 'blah' instead?
18:25:50 <devananda> rloo: sure. but how do we send such a warning back to the user?
18:25:58 <devananda> our API semantics don't provide a means for that
18:25:59 <jroll> in theory, we could add a response header or something to say it's deprecated, but that's a bit odd
18:26:12 <jroll> and doesn't help older clients
18:26:13 <rloo> i'm going to punt all this to the api group :)
18:26:15 <devananda> jroll: also, older clients (that might still be using o...
18:26:17 <jroll> :)
18:26:18 <devananda> yea
18:26:35 <rloo> i mean whatever ironic does, should follow what openstack does.
18:26:48 <devananda> rloo: I don't believe they've set a standard for this yet
18:26:53 <jroll> I guess the only true way is doing lots of mass communication, right? a la keystone v2->v3
18:26:57 <jroll> which we've seen doesn't work well
18:27:08 <rloo> maybe time to ask them to start then. so it'll be in place when we get there.
18:27:12 <devananda> jroll: I think that's different
18:27:38 <jroll> devananda: let me rephrase, that's the only prior art I've seen to dropping API things "gracefully"
18:28:36 <devananda> for example, what if at the 'P' release, we raised the minimum to 1.6 (Liberty, IIRC) ?
18:28:42 <devananda> that's two years / four cycles
18:29:08 <jroll> right, that seems reasonable in theory. but we still need to find a way to tell people
18:29:59 <rloo> wrt versioning: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
18:30:05 <devananda> do we need users / clients to change anything for that ?
18:30:13 * jroll pokes sean
18:30:17 <devananda> with keystone v2 -> v3, massive changes were / are required
18:30:39 <jroll> devananda: depends on the client, I guess
18:31:37 <jroll> for the ironic cli, it isn't a big pain, maybe upgrade it and request a different version
18:31:49 <jroll> for some client I built that only knows about 1.2, bigger pain
18:32:04 <devananda> rloo: oh, interesting tangent - we should update our headers to match that spec, I guess
18:32:29 <rloo> devananda: yup. i should open a bug about it.
18:32:39 <jroll> +1
18:33:20 <devananda> jroll: at least your client would be able to discover (by getting an error back from the server) that it was no longer compatible with that service
18:33:26 <devananda> jroll: deployers won't need to change anyuthing, though
18:33:37 <jroll> devananda: yeah, indeed
18:33:40 <devananda> that's been the biggest issue with key v3 -- deployers needed to run a new service
18:33:51 <devananda> so perhaps that's a good indication that we shouldn't do v2 as a separate service, actually.
18:34:06 * devananda is merely thinking through this outloud...
18:34:11 <jroll> yeah, I never envisioned us doing a separate service for v2
18:34:25 <jroll> but more a little shim to route /v1 and /v2 to the right tree in the code
18:34:32 <devananda> ah, I see
18:34:59 <devananda> if we did v2 as a separate framework, we might need to run it as a separate service
18:35:05 <devananda> or separate mod_wsgi plugin, etc
18:35:38 <jroll> I haven't tried, but I think it's possible to have a small wsgi app in front of both
18:35:45 <jroll> and pass it to v2.wsgi.__call__ or whatever
18:35:55 <jroll> everything is wsgi, thank $deity
18:36:00 <devananda> heh
18:36:08 <devananda> ok. I haven't seen that done, but maybe it is
18:36:25 <jroll> yeah, I'd have to play to confirm, but I think it's possible
18:36:34 <jroll> maybe that's a todo for the next week or two
18:36:48 * jroll wants to focus on resource_class stuff first though
18:37:03 <devananda> ++
18:37:59 <jroll> put a note in my todo list though, it's one of those things that's interesting enough to hack on for an hour or two
18:38:21 <rloo> speaking of resource_class... Jay sez it is OK for resource class value to be NULL so it might not be so urgent for ironic
18:38:35 <rloo> (but we can discuss outside of this meeting)
18:38:48 <jroll> +1, let's talk about that in channel after
18:39:18 <jroll> so things for next week
18:39:27 <jroll> 1) I'll actually formalize our grunts with v1 api
18:39:46 <jroll> 2) someone want to talk to API folks about bumping minimum microversion? maybe ML?
18:39:59 <jroll> 3) I'll play with dual-wsgi-framework things over the next week or two
18:40:02 <jroll> anything I missed?
18:40:17 <rloo> what about the end goal?
18:40:38 <rloo> i mean, all the others are means to get to the end goal. what is the new API going to look like?
18:41:19 <jroll> well, we decided last time that we want to get a spec up that includes: 1) current problems, 2) what the new thing looks like
18:41:23 <jroll> within the next couple months
18:41:35 <rloo> oh, that spec would be good then :)
18:41:37 <jroll> I think we need (1) agreed before we can do (2)
18:41:47 <devananda> +1
18:41:52 <jroll> and I don't have the time to do both in a single week :)
18:42:05 <devananda> I can spend a little time today starting on (1) in a new 'pad
18:42:07 <jroll> (or even one in one week, apparently)
18:42:10 <devananda> and sketchiing it into a spec-like structure
18:42:27 <jroll> devananda: that'd be helpful, I copied things from the midcycle pad into here https://etherpad.openstack.org/p/ironic-v2-api
18:42:32 <devananda> ah, great
18:42:35 <devananda> I'll edit in that
18:42:36 <jroll> and added quick notes from nova discussion
18:42:39 <jroll> +1
18:42:46 <rloo> that'd be great.
18:43:01 <jroll> I'll also attempt to contribute, but might not be until tomorrow or thursday
18:43:18 <jroll> s/attempt to// (I already said I'd do it heh)
18:43:18 <devananda> #action deva to draft current-pain-points in a spec like structure
18:43:46 <jroll> awesome, ty
18:44:00 <jroll> does anyone want to volunteer to start the deprecation discussion on the ML?
18:44:20 <jroll> (I'm happy to help summarize ideas/issues so far)
18:45:14 <jroll> *crickets*
18:45:21 <jroll> I can take that on
18:45:47 <rloo> i was going to say that if no one volunteered after 2 weeks, i'd do it. thx jroll :)
18:45:49 <jroll> alright, anything else today?
18:45:51 <jroll> lol
18:46:03 <jroll> rloo: saying that is just going to make me procrastinate :)
18:46:19 * devananda has nothing else right now
18:46:19 <rloo> jroll: you can procrastinate. the point is you volunteered!
18:46:39 <jroll> heh
18:46:47 <jroll> alright, let's get outta here
18:46:51 <jroll> #endmeeting