13:00:01 <alex_xu> #startmeeting nova api
13:00:02 <openstack> Meeting started Wed May 18 13:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:05 <openstack> The meeting name has been set to 'nova_api'
13:00:09 <alex_xu> who is here today?
13:00:12 <cdent> o/
13:00:58 <sdague> o/
13:01:13 <edleafe> \o
13:01:25 <jichen> o/
13:01:46 <alex_xu> ok, i think we can start the meeting
13:02:00 <alex_xu> #topic API Priorities
13:02:20 <alex_xu> let's talk about api-ref
13:02:47 <alex_xu> still have a lot of patches need review
13:02:51 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-ref-in-rst
13:03:12 <alex_xu> ah, not too much, just less than one page
13:03:27 <cdent> apologies for not participating in that but I was crunched under trying to get generic resource pools moved forward
13:03:27 <sdague> right, we still have a lot of work outstanding
13:03:44 <sdague> I updated the burndown with the list of files and where they stand - http://burndown.dague.org/
13:03:50 <alex_xu> cdent: congrats the resource pool spec merged
13:04:02 <cdent> alex_xu: one small step in many :)
13:04:16 <alex_xu> yeah, a lot of work
13:04:37 <sdague> so I think on the api-ref front we should decide what must be done before we switch to this being kind of constant background work
13:05:17 <sdague> and in my mind I think that's: flavors.inc, servers.inc, versions.inc, metadata.inc
13:05:30 <sdague> which are the more complicated ones
13:05:30 <alex_xu> sdague: +1, at least we can ask people write doc for any new api change in newton
13:05:52 <sdague> however, I think that if we get those sorted well this week, we're way better than the existing site
13:06:08 <alex_xu> ah, i point to the thing for supporting microversion, but i guess most of thing are done
13:06:17 <sdague> yeh
13:06:31 <sdague> there is still a few things we need to poc there
13:06:58 <johnthetubaguy> whats missing for microverisons now, roughly?
13:07:05 <alex_xu> sdague: do you have list
13:07:18 <johnthetubaguy> that max_version patch?
13:07:32 <sdague> max_version is landed
13:07:37 <johnthetubaguy> cool
13:07:38 <sdague> and in os-api-ref 0.1.1
13:07:45 <sdague> that I released yesterday
13:07:51 <sdague> you can see it in nova patches
13:08:29 <sdague> alex_xu: honestly, I haven't really built a detailed list on the next microversion steps here yet, I've been focussed on the os-api-ref release and getting the content right within the current constraints
13:08:53 <sdague> alex_xu: I think you had an old versions.inc patch, right?
13:09:02 <alex_xu> sdague: yes, i had one
13:09:20 <alex_xu> sdague: do we still want that?
13:09:26 <sdague> well, we want something :)
13:09:32 <sdague> I went through flavors yesterday
13:09:36 <sdague> it took a while
13:10:09 <sdague> so, mostly I'm looking to see if we could get volunteers on: servers.inc, versions.inc, metadata.inc for this week
13:10:16 <sdague> if not, I'll try to take one a day
13:10:29 <sdague> but splitting that up would be nice
13:10:36 <jichen> will spend some time , too
13:11:03 <sdague> jichen: cool, thanks
13:11:03 <alex_xu> ah, i already take versions.inc
13:11:09 <sdague> alex_xu: great, thank you
13:11:21 <sdague> jichen: you want to finish metadata.inc ?
13:11:24 <alex_xu> sdague: np
13:11:33 <johnthetubaguy> I will make time for the review side
13:11:40 <jichen> sdague: ok, I can
13:11:57 <sdague> great
13:12:15 <alex_xu> ok, we have plan for this week
13:12:18 <sdague> ok, I'll poke at servers.inc later this week then. And keep up the work on all the other files as well
13:12:44 <sdague> but those 4 getting landed defines some first stage done and we can do the rest as background during the cycle, and have a final sprint if needed
13:13:08 <alex_xu> ok, cool
13:13:26 <sdague> ok, I think we're good there. The only other thing to realize is os-api-ref is now a dedicated repo
13:13:35 <sdague> so fixes / patches / features should be proposed there
13:13:36 <johnthetubaguy> do we feel happy getting rid of the old site, once we have those three done?
13:14:05 <sdague> johnthetubaguy: yes, I think so, though anne is still coming up with how all these stitch together
13:14:20 <sdague> so I think we'll mostly work with her and follow her lead there
13:14:33 <sdague> but I would feel comfortable with this being the cannonical docs at this point
13:14:36 <johnthetubaguy> sounds good, I guess the key bit is we are not blocking her work their
13:14:40 <johnthetubaguy> yeah, +1
13:14:59 <alex_xu> ok, i think we can move on
13:15:03 <sdague> yep
13:15:09 * mriedem joins late
13:15:25 <alex_xu> for policy discovery, i saw the spec merged
13:15:43 <sdague> awesome
13:15:48 <alex_xu> #link Embed policy defaults in code
13:15:56 <alex_xu> #link https://review.openstack.org/290155
13:16:10 <alex_xu> sorry for the wrong link
13:16:47 <alex_xu> i think just waiting Andrew send out the base patch, when he need help on other part, he will reach to us
13:17:00 <sdague> sounds great
13:17:27 <alex_xu> anything else for policy?
13:17:28 <sdague> what's the bp topic for that for patches? I'll update the gerrit dash for priority reviews on that
13:17:36 <mriedem> sdague: doesn't exist yet
13:17:36 <mriedem> https://blueprints.launchpad.net/nova/+spec/policy-in-code
13:17:54 <mriedem> sdague: i've already got the needles into laski about it
13:18:02 <sdague> ok, cool
13:18:26 <mriedem> the oslo policy code has to land and release first
13:18:49 <sdague> ok, do we need to help review there as well?
13:19:07 <mriedem> https://blueprints.launchpad.net/oslo.policy/+spec/policy-in-code
13:19:25 <mriedem> no patches yet that i see in there
13:19:29 <alex_xu> just saw this patch
13:19:31 <mriedem> i'll ping jhesketh about approving the bp
13:19:32 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/oslo.policy+branch:master+topic:bp/policy-in-code
13:19:59 <sdague> cool, stared it for review
13:20:23 <alex_xu> #link https://review.openstack.org/309153
13:20:36 <alex_xu> one more spec for policy.json generate
13:21:24 <alex_xu> ok, i think this all for policy, let's move on?
13:22:07 <sdague> yes
13:22:12 <alex_xu> so we can begin to talk about deprecation
13:22:52 <sdague> sounds good, I went back through comments last night and here I think are the open issues
13:23:26 <sdague> * there are a few missing network related things that should be added (fping, net associate) (easy, non controversial)
13:24:23 <sdague> * there is an open question about how to help sites not build a bunch of software that's going to break (the big red button question), lets do that last
13:24:39 <sdague> * there is a question on whether we 404 the network apis at this microversion
13:24:47 <sdague> (which mriedem does not like)
13:25:17 <johnthetubaguy> yeah, I kinda like the 404 as a signal that they are going away
13:25:20 <mriedem> in part because nova-network isn't a proxy api
13:25:24 <johnthetubaguy> it shouldn't break existing users scripts
13:25:44 <mriedem> but neither is fping i guess
13:25:45 <sdague> johnthetubaguy: well, it will if they move up the microversion
13:25:59 <sdague> mriedem: well fping only works with nova net in most cases
13:26:10 <mriedem> yeah, so the spec started out being about proxy apis
13:26:19 <mriedem> and it's easier to think of a big hammer on those
13:26:31 <mriedem> but other nova-net specific wrinkles makes this mesier
13:26:34 <mriedem> *messier
13:26:43 <johnthetubaguy> sdague: ack, if they do that for those requests
13:27:11 <sdague> ok... so, how do we want to navigate this?
13:27:13 <mriedem> plus as a client do i know or care what backend networking is being used?
13:27:18 <johnthetubaguy> so what is the alternative for nova-net?
13:27:38 <johnthetubaguy> we deprecate the APIs after we remove nova-net?
13:27:40 <sdague> mriedem: at some level, yes, because what you can do is quite different
13:27:55 <mriedem> sdague: yeah i'm sure i could figure it out via trial and error
13:27:57 <mriedem> but still, that sucks
13:28:02 <mriedem> but it's latent suck i guess :)
13:28:03 <sdague> mriedem: I agree
13:28:05 <johnthetubaguy> mriedem: agreed it sucks
13:28:22 <sdague> hence, why we're deprecating nova-net, because eventually you'll know as nova-net isn't an option
13:28:33 <mriedem> the problem i have with a 404 on nova-network requests is, with proxies it's easy - go use neutron/cinder/glance/ironic apis
13:28:36 <cdent> what matters more: transitional suck, or eternal suck?
13:28:44 <mriedem> but with nova-net, you can't use neutron apis
13:28:53 <mriedem> you have to use the nova apis for nova-net until that cloud moves to neutron
13:29:10 <mriedem> so then you have to pin any network-related requests you make < the deprecation microversion
13:29:11 <sdague> mriedem: right, which just means you don't get new Nova features in your cloud
13:29:12 <johnthetubaguy> so security groups and floating ips are the sticking point here?
13:29:29 <sdague> which, I'm not sure why that's an issue
13:29:37 <alex_xu> but deprecated by microvesion, if user not upgrade to new microversion, so he will be fine
13:29:41 <mriedem> just seems like we're pushing a lot of complexity on the client
13:29:49 <sdague> mriedem: why?
13:30:02 <mriedem> sdague: to special case their calls based on microversion
13:30:08 <mriedem> unless they just cap at this version and don't move ahead
13:30:10 <mriedem> until they are off nova-net
13:30:13 <sdague> mriedem: right
13:30:16 <sdague> and that's my suggestion
13:30:18 <johnthetubaguy> I feel like we are warning the client that these old APIs are going away
13:30:20 <sdague> they cap at 2.25
13:30:36 <johnthetubaguy> if we don't warn, what do we do when we drop nova-net?
13:30:41 <sdague> and they just don't get new nova features until their cloud moves on
13:30:44 <sdague> johnthetubaguy: exactly
13:30:46 <mriedem> and as a client i can't really do anything about that until the cloud endpoint i'm talking to moves on, or i move on, or i special case my code
13:30:55 <sdague> mriedem: right, but just "2.25"
13:31:07 <sdague> we're assuming this is done with a single global in code
13:31:10 <mriedem> yeah, but see i really really want 2.40 :)
13:31:11 <sdague> that's tested on that version
13:31:12 <johnthetubaguy> or keep using v2.0 or v2.1 base version
13:31:18 <sdague> mriedem: well, honestly, too bad
13:31:23 <johnthetubaguy> like they probably are, since we haven't documented any microversion
13:31:29 <sdague> we're about to actually delete all this code in 2 cycles
13:31:40 <mriedem> johnthetubaguy: except novaclient
13:31:47 <sdague> continuing to make it easy for people to use it up until it's ripped out from under them seems weird
13:31:59 <alex_xu> emm...one more thing, it is safe for v2.1 compat mode?
13:32:11 <sdague> for the 7% of users still hitting nova-net
13:32:17 <johnthetubaguy> mriedem: only the CLI
13:32:25 <johnthetubaguy> mriedem: which we can fix
13:32:33 <sdague> we honestly need to stop treating nova-net sites and users as first class citizens
13:32:40 <sdague> nova net is deprecated, they are not any more
13:32:55 <johnthetubaguy> so here is an alternative...
13:33:02 <johnthetubaguy> today: deprecate nova-net
13:33:09 <johnthetubaguy> next cycle: deprecate the nova-net APIs
13:33:21 <johnthetubaguy> i.e. give folks a warning its going to get really hard, real soon
13:33:22 <mriedem> today is already done
13:33:25 <johnthetubaguy> right
13:33:43 <sdague> and that means when we delete in P they've only had 6 months warning
13:33:56 <sdague> we deprecated the code that powers those APIs
13:34:10 <sdague> I don't understand how those APIs are not also deprecated and blocked in a microversion
13:34:10 <mriedem> i think people probably need a year at least for this
13:34:41 <mriedem> like people are just upgrading to kilo now because it's going end of life
13:34:48 <mriedem> so i think 6 months is a bit harsh yeah
13:34:53 <sdague> making APIs first class for deprecated code... just seems like all the wrong messaging
13:35:13 <cdent> mriedem: if they are only just upgrading to kilo now, then a six month window in master-based time is 18 months?
13:35:26 <cdent> (in kilo-based time?)
13:35:35 <cdent> which is a _lot_ of time
13:35:43 <mriedem> cdent: idk, my gut is when they get to newton, we've already ripped out nova-net
13:35:50 <mriedem> because they are so far behind
13:35:51 <sdague> mriedem: right
13:36:11 <sdague> so, people that far behind, honestly don't get to be part of the conversation.
13:36:25 <mriedem> so if we're saying people just need to cap in their clients until their cloud moves to nova-net, then i guess i'm fine with that
13:36:36 <sdague> mriedem: right, I think that's what we're saying
13:36:43 <sdague> at least that's what I'm saying
13:36:45 <mriedem> when i originally read the spec i was thinking people would have to special case their calls
13:36:53 <mriedem> i think we should be very clear about that in the spec
13:36:58 <sdague> sure, I can make that clear
13:37:03 <sdague> so that was point #3
13:37:16 <sdague> seems like we have resolution there
13:37:25 <sdague> point #2 - big red switch
13:37:57 <sdague> i.e. do we provide an easy config option for adminstrators to disable deprecated APIs (all of them, not getting to pick / choose)
13:38:25 <sdague> mostly as a defensive mechanism to help prevent their users from building code against APIs that will go away
13:38:57 <sdague> this is really the meta issue of how to communicate to end user apps they are using deprecated stuff
13:39:10 <alex_xu> unless administrator knew that will break the old client.
13:39:33 <mriedem> btw, before we move on from the nova-net thing, no one answered alex_xu's question about v2.1 compat mode
13:39:49 <sdague> ok, alex_xu what's the question on the v2.1 compat mode?
13:40:04 <mriedem> actually it wouldn't be a problem
13:40:13 <mriedem> alex_xu: because that's just a v2.1 request
13:40:17 <mriedem> not v2.26 or whatever
13:40:30 <alex_xu> i think we should keep all the proxy api works for v2.1 compat mode. and what happen after we remove nova-net in v2.1 compat mode?
13:40:42 <mriedem> if we delete the nova-net code, then yes v2.1 compat and everything below the deprecation microversion is busted
13:41:15 <sdague> alex_xu: at some point, we have to drop these proxies
13:41:26 <mriedem> we can't delete nova-net unless we raise the minimum microversion past the deprecation microversion
13:41:42 <mriedem> alex_xu: for the proxies, we aren't dropping the code, just giving a 404 after a certain microversion
13:41:43 <mriedem> to signal
13:41:50 <mriedem> so we can eventually raise the minimum required version and then drop the code
13:41:51 <sdague> mriedem: that's what concerns me
13:42:05 <sdague> because what that means is nova-network exists until the T release (at least)
13:42:08 <alex_xu> mriedem: yea, need raise the min version
13:42:13 <sdague> and all that code is massively rotted
13:42:14 <mriedem> sdague: or,
13:42:19 <mriedem> well,
13:42:32 <mriedem> i was going to say, it moves out of tree and we just call it, but don't really maintain it,
13:42:39 <sdague> right, which is just dumb
13:42:40 <mriedem> but we would still need to test it i tihnk
13:42:52 <sdague> which means someone has to fix it
13:42:56 <mriedem> yeah
13:43:01 <sdague> and no one will
13:43:10 <mriedem> vish might :)
13:43:18 <mriedem> j/k
13:43:22 <sdague> I get that this is a violation of our norms, but it is a special case
13:43:39 <mriedem> so,
13:43:47 <sdague> we did the same thing with the XML drop
13:43:47 <mriedem> we don't need to decide if we're going to drop the code this cycle
13:43:52 <sdague> right
13:44:06 <sdague> I honestly think the delete is in P
13:44:07 <mriedem> getting the deprecation microversion in place doesn't break v2.1 or compat mode
13:44:10 <sdague> right
13:44:18 <sdague> but it gets signalling early
13:44:23 <mriedem> so let's punt on the deleting part
13:44:30 <alex_xu> if all the network api is extension in legacy v2, i think we can remove then by removing them from the extension api also.
13:44:30 <sdague> so we can get people prepared
13:45:01 <sdague> ok, so... big red switch?
13:45:20 <cdent> yes
13:45:24 <sdague> because that's the thing I want to discuss before doing the rev of the spec
13:45:29 <sdague> as I think that's the last sticking point
13:45:30 <alex_xu> ok, i'm ok with that, let talk about big red switch
13:46:07 <mriedem> i was wondering why deployers that wanted this couldn't just disable the apis via policy?
13:46:15 <mriedem> there might have already been a reason that i'm forgetting
13:46:26 <sdague> mriedem: because it's super complicated
13:46:41 <sdague> and it means that inevitably everyone would do it differently
13:46:51 <sdague> so few people actually modify policy
13:47:09 <mriedem> ok, but by the same logic, wouldn't a big red switch put a big x on interop?
13:47:12 <sdague> the situation I'm thinking about is we get to P cycle
13:47:17 <johnthetubaguy> yeah, most folks always fail at policy changes
13:47:26 <sdague> people have deployed Newton clouds
13:47:37 <alex_xu> so...we have red button, which leads to the api return 403...
13:47:46 <sdague> we dropped nova-net in P
13:47:59 <sdague> which means anything using any of that is broken
13:48:18 <sdague> the cloud would really like to signal their users early about this
13:48:43 <sdague> so they don't have a ton of new software written against newton that is guarunteed to break
13:48:51 <sdague> and piss everyone off
13:49:21 <mriedem> if you're basing this on the assumption that we drop nova-net in P, i think that has to be sorted out first,
13:49:22 <mriedem> but go on
13:49:37 <sdague> well, we're going to drop something sometime
13:49:44 <sdague> move back 2 releases
13:50:03 <sdague> how do sites manage to premtively help their users no use deprecated apis
13:50:07 * alex_xu reminders 10 mins left
13:50:10 <sdague> to help them move forward
13:50:20 <johnthetubaguy> right, thats my worry
13:50:42 <sdague> let's be honest, deleting stuff is hard, it's always hard
13:50:45 <mriedem> and if their app is already written using apis from kilo, it's already too late
13:50:51 <sdague> mriedem: sure
13:51:07 <sdague> but the longer that exists the worse the problem gets
13:51:10 <mriedem> so dropping the big red switch will break them - they'd obviously have to give some lead time on that
13:51:23 <sdague> sure, which is part of making it an ops switch
13:51:24 <mriedem> i.e. in 6 months this cloud is going to turn off these apis, so rev your code
13:51:38 <sdague> disable_deprecated_apis=True
13:51:59 <sdague> they could even set that for only 1 set of compute endpoints
13:52:09 <sdague> so there is a legacy endpoint, and a clean endpoint
13:52:30 <sdague> and people could try their code against the clean endpoint, and see if it works
13:52:35 <mriedem> i was thinking, what if we deprecate some other api in ocata? if disable_deprecated_apis is a global, then the deprecation in ocata has 0 lead time
13:52:47 <sdague> mriedem: yes
13:52:58 <cdent> I was just going to ask that sdague : so it would be possible to run two different apis: go the default one blow up with a message that says if you insist, reconfigured to use endpoint X ?
13:53:02 <mriedem> but making the deprecation thing a list is also gross
13:53:14 <sdague> mriedem: right, and leads to worse interop
13:53:22 <cdent> s/reconfigured/reconfigure/
13:53:30 <sdague> cdent: yeh, API is an n-way service
13:53:41 <cdent> that seems like a very sane way to go
13:53:53 <cdent> as long as the associated messaging was clear
13:53:55 <sdague> you could definitely have multiple of them, talking to the same backend, some with it on and some with it off
13:54:25 <mriedem> heh, compat mode for the deprecated apis
13:54:32 <mriedem> which have compat mode to v2.0
13:54:38 <mriedem> a smelly onion
13:54:45 <mriedem> i like the multiple endpoint idea though
13:54:46 <mriedem> as a backdoor
13:55:05 <edleafe> won't we have to close that backdoor eventually, too?
13:55:22 <sdague> edleafe: it's called deleteing the actual code
13:55:24 <cdent> presumably the messaging would need to say "the backdoor wil live for N days"
13:55:43 <mriedem> yeah ,the backdoor is broken when the deprecated apis are gone
13:55:47 <mriedem> or just don't work anymore
13:55:49 <sdague> yep
13:55:55 * alex_xu reminders 5 mins left
13:56:03 <mriedem> sdague: so before we move forward with something like this, i think it needs advertising on the dev and ops lists
13:56:16 <sdague> mriedem: ok, so how do we want to handle the spec then?
13:56:34 <sdague> do an email around this to ops / dev asking for feedback ?
13:56:38 <mriedem> i think propose what you want for the red switch with the backdoor
13:56:55 <mriedem> and then yes bring it up in the lists for feedback
13:57:15 <mriedem> because we're providing a way for ops to do something, but we should make sure it's something they'll want or use
13:57:17 <mriedem> or if we're missing something
13:57:18 <sdague> ok, and we move forward on the current spec without it for now
13:57:23 <sdague> so it can progress
13:57:34 <sdague> then this comes in as ... another spec?
13:57:36 <mriedem> yeah or that, the kill switch could be a separate spec
13:57:53 <mriedem> we're all on board with the deprecation spec w/o the kill switch i think
13:57:53 <sdague> right, I mostly want to make sure we move forward on the proxy deprecation in some form
13:57:57 <mriedem> so if you want to move that forward, yes
13:58:12 <sdague> ok, sounds good, I'll redo it based on that feedback (and the other bits above)
13:58:22 <mriedem> specs are cheap and plentiful!
13:58:23 <sdague> * will propose to ops about the kill switch
13:58:40 <sdague> * will (at some point) also propose some other extensions to deprecate
13:58:45 <alex_xu> cool, i think i will cut the meeting in next minutes
13:58:46 <cdent> what's the link to the spec(s) being discussed?
13:58:46 <sdague> as a 3rd spec
13:59:04 <sdague> cdent: https://review.openstack.org/#/c/312209/ is the proxy deprecation spec
13:59:10 <cdent> thanks sdague
13:59:17 <mriedem> if you have input on bdm v1 in the dev list please respond
13:59:23 <mriedem> but i think it falls into the same bit rot category
13:59:25 <mriedem> we don't test it
13:59:30 <mriedem> and it crufts up the bdm code all over nova
13:59:43 <alex_xu> ok, let's move back to the openstack-nova, i will cut the meeting
13:59:48 <mriedem> thanks
13:59:49 <alex_xu> thanks all!
13:59:52 <sdague> yep, I think I'm good here, thanks all
13:59:53 <alex_xu> #endmeeting