00:00:54 <cyeoh> #startmeeting nova-api
00:00:55 <openstack> Meeting started Fri May  9 00:00:54 2014 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:00 <openstack> The meeting name has been set to 'nova_api'
00:01:12 <cyeoh> Hi - who do we have here today?
00:01:16 <anteaya> o/
00:01:17 <alex_xu> Hi
00:01:18 <anteaya> yay
00:01:33 <anteaya> I'm just so happy you are back, cyeoh
00:01:35 <anteaya> :D
00:01:38 <oomichi> hi
00:01:45 <cyeoh> anteaya: thanks - great to be back :-)
00:01:48 <anteaya> :D
00:01:59 <melwitt> o/
00:02:01 <oomichi> yea, nice to back:)
00:02:16 <tinoue> o/
00:02:16 <cyeoh> :-)
00:02:31 <cyeoh> #topic design summit
00:02:35 <GMann> welcome back :)
00:02:45 <cyeoh> GMann: thanks!
00:02:45 <alex_xu> and cyeoh sound pretty great on the call :)
00:03:29 <melwitt> yes welcome back
00:03:31 <cyeoh> so we have 2 design summit sessions next week on the Nova API
00:03:54 <cyeoh> the first is the V2.1 on V3 API one and then a second one on the V3 API itself
00:04:08 <cyeoh> oomichi: thanks for setting up the etherpads - I've started mangling them a bit :-)
00:04:20 <cyeoh> #link https://etherpad.openstack.org/p/juno-nova-v2-on-v3-api-poc
00:04:21 <oomichi> not only me, alex_xu also:)
00:04:33 <cyeoh> alex_xu: thanks too :-)
00:04:38 <alex_xu> np :)
00:05:00 <cyeoh> so I've started working on the V2.1 on V3 API one just to try to get a bit of a flow of how we might walkthrough/discuss what is going on
00:05:37 <cyeoh> I imagine it will end up being pretty open discussion but just want to make sure we cover all the reasonings behind why we did what we did
00:05:46 <cyeoh> and not just what we did
00:06:35 <cyeoh> also I think its important to emphasise that if we're comparing backporting V3 API features (like plugins etc to V2) then doing a V2.1 on V3 is in comparison a better path than trying to modify the V2 code base in place)
00:07:16 <oomichi> cyeoh: agree, that is important point.
00:07:41 <alex_xu> cyeoh, +1
00:08:04 <cyeoh> oomichi: so I haven't actually tried to run the V2.1 POC code in devstack recently - is it looking ok at the moment? (I guess not much is merging at the moment anyway)
00:08:28 <oomichi> cyeoh: yea, enough for now.
00:08:57 <oomichi> cyeoh: I think we need to change Tempest code also for v2.1 for production.
00:09:23 <oomichi> but now, for just PoC, current code is already enough.
00:09:32 <cyeoh> oomichi: what sort of changes do you think we need on the tempest side? Is that input validation related?
00:10:01 <oomichi> cyeoh: we need to run Temepst against v2, v2.1 and v3 in the future.
00:10:28 <oomichi> cyeoh: for doing it, we need to add endpoint of v2.1 to Tempest.
00:10:50 <cyeoh> oomichi: so I we might be able to handle that on the devstack side. By running a full tempest job with /v2.1 exported as /v2 instead?
00:11:15 <cyeoh> when we get close we could run that as an experimental job on demand
00:11:46 <oomichi> that is one of good tests.
00:12:11 <oomichi> I guess we need to run v2, v2.1, v3 API tests in paralell.
00:12:25 <oomichi> until v2 is deprecated or removed.
00:12:55 <cyeoh> oomichi: yes, I think that will end up being necessary, though hopefully the v2 codebase can be fairly quickly deprecated what v2.1 is proven.
00:12:57 <oomichi> so we will need to create tests for v2.1 API also.
00:13:34 <cyeoh> oomichi: are you talking about unittests?
00:13:55 <oomichi> yes, right. just v2.1 API test can inherit from current v2 API test.
00:14:03 <oomichi> no, about Tempest.
00:14:32 <cyeoh> for tempest though with the exception of input validation we're meant to behave exactly the same though
00:14:40 <cyeoh> so do we need v2.1 versions of tests?
00:15:18 <oomichi> v2.1 API test can inherit from current v2 API test with *different endpoint*
00:15:54 <oomichi> I will send a mail with the detail of in my head.
00:16:06 <cyeoh> hrm ok :-)
00:16:28 <oomichi> I can explain it with some code :)
00:16:42 <cyeoh> I think in Juno we'll try to do a bit of work on the tempest side anyway to reduce the amount of duplication we have just between v2 and v3 as well so it might all fit together well...
00:17:11 <oomichi> cyeoh; yea, that is a point for v2.1 API tests also.
00:17:20 <cyeoh> cool :-)
00:17:54 <oomichi> anyway, I will send the detail after refresh my head:-)
00:18:05 <cyeoh> oomichi: thanks :-)
00:18:31 <cyeoh> so for the V3 API session I think the etherpad already covers the major things we want
00:18:47 <cyeoh> I don't know if there will be another big discussion over whether to do the V3 API or not, but we'll just have to wait and see :-)
00:19:26 <cyeoh> I do really want to talk about the tasks api and alaski has said he'll put together a bit of info for the session so we can discuss that.
00:19:37 <cyeoh> it's something I think we really need to do in Juno
00:19:37 <melwitt> +1
00:19:57 <tinoue> +1
00:20:11 <cyeoh> melwitt: yea and I apologise I hadn't really meant to ignore your multiple create server patch but its all rather dependent on what happens with tasks
00:20:32 <cyeoh> everything gets a whole lot cleaner if we have tasks :-)
00:20:41 <melwitt> cyeoh: I know. :) no worry
00:21:44 <cyeoh> while I remember one thing which might come up on python novaclient is that during the whole v2/v3 discussions there was definitely a desire by some that the novaclient interface remain the same between v2 and v3
00:21:59 <cyeoh> but unfortunately python novaclient is very very thin wrapper on top of the REST API
00:22:38 <melwitt> yeah. good to know that's something to consider
00:22:45 <cyeoh> so whilst novaclient could protect users of novaclient from any visible changes (eg camelcase changes etc) we probably need to discuss whether it should - or if a major version bump allows us to make backwards incompatible changes like we do with the REST API
00:23:32 <melwitt> agree
00:24:11 <cyeoh> I think what I'd like out of the V3 API session as a whole in the end is to try to settle on some objective criteria about when we can release as stable
00:24:31 <melwitt> there's a lot brewing lately with the clients, the Client Tools program which is working on the unified client, and then an effort to support keystone sessions in clients so we can use keystone v3 api
00:25:14 <cyeoh> melwitt: yea there is a whole lot going on there. And to be honest python-novaclient is really hacky - lots of horrible stuff to auth to multiple services
00:25:31 <melwitt> cyeoh: yes, it definitely is
00:25:36 <cyeoh> it'd be nice if it all got thrown away and started again :-)
00:26:07 <melwitt> :)
00:26:25 <melwitt> I'm not sure yet how far along openstack client is, but that'll be when
00:26:52 <anteaya> I think there is a summit session on openstackclient
00:27:02 <cyeoh> cool :-)
00:27:16 <cyeoh> #topic consistency across Openstack REST APIs
00:27:27 <cyeoh> #link http://junodesignsummit.sched.org/event/ddf93f2ad9c1798306889d7edaac9b7d#.U2jjxKZ1be8
00:27:46 <cyeoh> so I submitted this session and now I won't be able to attend (probably not remotely either because of the time)
00:28:01 <anteaya> http://junodesignsummit.sched.org/event/ae9afc77278abb98f0fc35a540a1bb0b#.U2whBXKZg5k
00:29:17 <cyeoh> anteaya: thx - yea it'll be very interesting to see how progress is going there - I think there has been some debate around consuming things like python-novaclient versus just replacing them too
00:30:06 <anteaya> yes
00:30:13 <cyeoh> re: openstack REST API consistency - I originally submitted this session because I think its really important that all the openstack projects converge on similar "look and feel" for their rest APIs
00:30:41 <anteaya> my sense is it will be well attended
00:30:46 <cyeoh> everything from nomenclature - eg so one API doesn't refer to "server groups" whilst another refers to the same concept as "instance groups"
00:31:30 <cyeoh> to how we handle backwards compatible changes (major version bumps, rolliing version bumps etc). Otherwise it'll become a nightmare for users of different APIs
00:31:31 <melwitt> good session
00:32:05 <cyeoh> anyway I just want to encourage people to attend the session :-)
00:32:14 <oomichi> yea, inconsistency would make difficult to implemet some APPs by developers/users.
00:32:46 <oomichi> will attend it:)
00:32:52 <anteaya> cyeoh: who will be chairing the session in your absence?
00:32:52 <GMann> interesting session and Would like to attend this.
00:33:36 <anteaya> and there is a part 2 for it
00:33:48 <cyeoh> anteaya: I've asked Jon Grimm (from IBM) if he could and though he's not that familiar with it he's happy to. I'm going to write up some more etherpad info, but really if anyone wants to lead it they're welcome to :-)
00:34:03 <anteaya> http://junodesignsummit.sched.org/event/74a65c82252d6998137af945698c8bdc#.U2wiTXKZg5k
00:34:24 <anteaya> I think a lot of people are looking forward to these sessions
00:34:27 <cyeoh> oh wow, I didn't know there was a part 2!
00:34:40 <anteaya> so if Jon Grimm wants to chair, that will be great
00:34:48 <cyeoh> I guess there is a lot of interest in it then
00:35:10 <anteaya> cyeoh: russellb was organizing the cross-project part, so I am assuming this is why he proposed part 2
00:35:15 <anteaya> yes a lot of interest
00:35:28 <anteaya> so knowing who the chair will be helpful
00:35:54 <anteaya> I don't want to put pressure on you, cyeoh so talk to mikal or russellb to ensure all is organized
00:36:31 <anteaya> I'd offer to help but I know zip about the topic
00:36:37 <anteaya> so Jon is a better choice
00:36:45 <cyeoh> Ok. So Jon will lead it if no one else wants to - but if anyone here would like to please put up their hands?
00:37:27 <cyeoh> Because its cross project I think everyone from the various projects will bring a lot of useful experience to it. I think we just need to summarise some of the major pain points etc
00:37:37 <cyeoh> and leave it to a fairly open discussion.
00:38:07 <anteaya> I agree with that assessment
00:38:12 <cyeoh> I think what I'd like to see as an outcome is an agreement to commit to ongoing documentation of conventions re: development of the REST APIs
00:38:35 <cyeoh> so the bigger projects converge very slowly over time. And the new smaller ones don't end up of a completely different tangent
00:39:02 <melwitt> are the pain points already summarized somewhere? I don't mind leading it but not sure I have enough info other than my own experiences and users of our cloud
00:39:40 <cyeoh> melwitt: not really - I'm just going to try to summarise the pain that I've seen through Nova API development
00:40:11 <cyeoh> and hopefully through discussion in the session that will prompt people from other projects to bring up their experiences
00:40:19 <melwitt> yeah
00:40:44 <anteaya> melwitt: if you come in with your experience and work with cyeoh to learn as much as you can about the history of his work, the rest of the group will fill in the blanks
00:40:59 <anteaya> melwitt: were you in hong kong at teh design summit there?
00:41:25 <melwitt> anteaya: yes, attended nearly all the nova design sessions in HK
00:41:35 <anteaya> melwitt: great
00:41:47 <anteaya> so the flow will be similar
00:41:59 <anteaya> and others will jump in if you need their input
00:43:01 <cyeoh> ok so I think we'll be fine for that session then.
00:43:16 <cyeoh> #topic input validation for names
00:43:28 <cyeoh> I kind of threw this one on the agenda a couple of weeks ago and then didn't turn up :-)
00:43:40 <anteaya> you were busy
00:43:50 <cyeoh> anteaya: a little distracted yes :-)
00:43:57 <melwitt> anteaya: (sorry for the late comment) sure. well, if a better match isn't found, I'd be happy to lead it/start the discussion and get people talking on the topic
00:44:20 <anteaya> melwitt: I think it is best if you just decide now to do it
00:44:27 <anteaya> then you can start preparing
00:44:50 <melwitt> anteaya: okay, I can commit to it. thanks
00:44:59 <anteaya> go you, you will be great
00:45:05 <anteaya> sorry cyeoh
00:45:12 <cyeoh> melwitt: cool - thanks! You will be great :-)
00:45:23 <melwitt> thanks anteaya and cyeoh :)
00:45:49 <cyeoh> so with the input validation in V3 (and by implication v2.1) we are getting much more consistent with what is considered a valid name
00:45:59 <cyeoh> whether it be a keypair name, instance name etc
00:46:07 <cyeoh> which is all very good for the future
00:46:30 <cyeoh> but I'm slightly concerned that with a v2 -> v2.1 transition that we may end up with some names which were valid under v2 but are not valid under v2.1/v3
00:47:01 <cyeoh> anyway I have a todo on myself to contact hp/rackspace people to supply them with a regexp to look through the dbs to see if in practice if its a problem
00:47:13 <cyeoh> eg do people really use leading spaces for instance names etc
00:47:16 <oomichi> cyeoh: ah, yes. we can not specify local chars(japanese, etc.) as server name on v2.1 and v3 API.
00:47:54 <cyeoh> oomichi: yea I wonder if we'll need to relax those regexps in the end - but certainly relaxing them is a whole lot easier than tightening them :-)
00:48:35 <cyeoh> hopefully its a non-issue but I wanted to make sure everyone was aware of it.
00:48:45 <oomichi> cyeoh: yes, we need to do it if really necessary.
00:49:06 <cyeoh> #topic api extension tasks
00:49:12 <cyeoh> oomichi: I think this is yours?
00:49:19 <oomichi> cyeoh: yes
00:49:47 <oomichi> cyeoh: and you have already approved one topic just before this meeting, thanks:)
00:49:55 <cyeoh> np - good work :-)
00:50:34 <oomichi> thanks
00:50:49 <oomichi> and we need to keep api extension names also consistent.
00:51:03 <oomichi> I will try it on Tempest side.
00:51:06 <cyeoh> I agree we should keep the names consistent (it doesn't hurt at all)
00:51:21 <oomichi> with https://review.openstack.org/#/c/92010/
00:51:50 <oomichi> should we do it on Nova unit tests ? or is it OK to do it on Tempest side?
00:52:12 <cyeoh> oomichi: oh thats a good point - we could probably do it via unit tests
00:52:44 <oomichi> oh, OK. will try it on unit tests:)
00:52:45 <cyeoh> better to catch it on the Nova side (though doesn't hurt to check on tempest as well - and its something we should encourage other projects to do as well)
00:53:25 <oomichi> thanks, that is all from me:)
00:53:37 <cyeoh> oomichi: might even just do it on the plugin loader - it could refuse to load the module if the name is badly formatted
00:53:57 <cyeoh> #topic open discussion
00:54:10 <cyeoh> anything anyone else wanted to talk about?
00:55:13 <cyeoh> ok, thanks all for attending. Will talk to you all later!
00:55:21 <melwitt> cyeoh: would you like to send me something or point me to some references to dig into before the session, so I can summarize them for everyone?
00:55:45 <cyeoh> melwitt: sure - I will put some notes together and email them to you
00:55:51 <melwitt> I can come up with things on my own but if you have anything, I'm glad to use it
00:56:00 <melwitt> cyeoh: thanks!
00:56:03 <cyeoh> might not be today though but I will definitely send you some things :-)
00:56:17 <anteaya> cyeoh: great meeting!
00:56:33 <melwitt> cyeoh: okay, no rush. just sometime before the session :) appreciate it
00:56:52 <cyeoh> cya all!
00:57:02 <cyeoh> #endmeeting