00:00:54 #startmeeting nova-api 00:00:55 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:00 The meeting name has been set to 'nova_api' 00:01:12 Hi - who do we have here today? 00:01:16 o/ 00:01:17 Hi 00:01:18 yay 00:01:33 I'm just so happy you are back, cyeoh 00:01:35 :D 00:01:38 hi 00:01:45 anteaya: thanks - great to be back :-) 00:01:48 :D 00:01:59 o/ 00:02:01 yea, nice to back:) 00:02:16 o/ 00:02:16 :-) 00:02:31 #topic design summit 00:02:35 welcome back :) 00:02:45 GMann: thanks! 00:02:45 and cyeoh sound pretty great on the call :) 00:03:29 yes welcome back 00:03:31 so we have 2 design summit sessions next week on the Nova API 00:03:54 the first is the V2.1 on V3 API one and then a second one on the V3 API itself 00:04:08 oomichi: thanks for setting up the etherpads - I've started mangling them a bit :-) 00:04:20 #link https://etherpad.openstack.org/p/juno-nova-v2-on-v3-api-poc 00:04:21 not only me, alex_xu also:) 00:04:33 alex_xu: thanks too :-) 00:04:38 np :) 00:05:00 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 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 and not just what we did 00:06:35 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 cyeoh: agree, that is important point. 00:07:41 cyeoh, +1 00:08:04 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 cyeoh: yea, enough for now. 00:08:57 cyeoh: I think we need to change Tempest code also for v2.1 for production. 00:09:23 but now, for just PoC, current code is already enough. 00:09:32 oomichi: what sort of changes do you think we need on the tempest side? Is that input validation related? 00:10:01 cyeoh: we need to run Temepst against v2, v2.1 and v3 in the future. 00:10:28 cyeoh: for doing it, we need to add endpoint of v2.1 to Tempest. 00:10:50 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 when we get close we could run that as an experimental job on demand 00:11:46 that is one of good tests. 00:12:11 I guess we need to run v2, v2.1, v3 API tests in paralell. 00:12:25 until v2 is deprecated or removed. 00:12:55 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 so we will need to create tests for v2.1 API also. 00:13:34 oomichi: are you talking about unittests? 00:13:55 yes, right. just v2.1 API test can inherit from current v2 API test. 00:14:03 no, about Tempest. 00:14:32 for tempest though with the exception of input validation we're meant to behave exactly the same though 00:14:40 so do we need v2.1 versions of tests? 00:15:18 v2.1 API test can inherit from current v2 API test with *different endpoint* 00:15:54 I will send a mail with the detail of in my head. 00:16:06 hrm ok :-) 00:16:28 I can explain it with some code :) 00:16:42 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 cyeoh; yea, that is a point for v2.1 API tests also. 00:17:20 cool :-) 00:17:54 anyway, I will send the detail after refresh my head:-) 00:18:05 oomichi: thanks :-) 00:18:31 so for the V3 API session I think the etherpad already covers the major things we want 00:18:47 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 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 it's something I think we really need to do in Juno 00:19:37 +1 00:19:57 +1 00:20:11 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 everything gets a whole lot cleaner if we have tasks :-) 00:20:41 cyeoh: I know. :) no worry 00:21:44 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 but unfortunately python novaclient is very very thin wrapper on top of the REST API 00:22:38 yeah. good to know that's something to consider 00:22:45 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 agree 00:24:11 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 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 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 cyeoh: yes, it definitely is 00:25:36 it'd be nice if it all got thrown away and started again :-) 00:26:07 :) 00:26:25 I'm not sure yet how far along openstack client is, but that'll be when 00:26:52 I think there is a summit session on openstackclient 00:27:02 cool :-) 00:27:16 #topic consistency across Openstack REST APIs 00:27:27 #link http://junodesignsummit.sched.org/event/ddf93f2ad9c1798306889d7edaac9b7d#.U2jjxKZ1be8 00:27:46 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 http://junodesignsummit.sched.org/event/ae9afc77278abb98f0fc35a540a1bb0b#.U2whBXKZg5k 00:29:17 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 yes 00:30:13 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 my sense is it will be well attended 00:30:46 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 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 good session 00:32:05 anyway I just want to encourage people to attend the session :-) 00:32:14 yea, inconsistency would make difficult to implemet some APPs by developers/users. 00:32:46 will attend it:) 00:32:52 cyeoh: who will be chairing the session in your absence? 00:32:52 interesting session and Would like to attend this. 00:33:36 and there is a part 2 for it 00:33:48 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 http://junodesignsummit.sched.org/event/74a65c82252d6998137af945698c8bdc#.U2wiTXKZg5k 00:34:24 I think a lot of people are looking forward to these sessions 00:34:27 oh wow, I didn't know there was a part 2! 00:34:40 so if Jon Grimm wants to chair, that will be great 00:34:48 I guess there is a lot of interest in it then 00:35:10 cyeoh: russellb was organizing the cross-project part, so I am assuming this is why he proposed part 2 00:35:15 yes a lot of interest 00:35:28 so knowing who the chair will be helpful 00:35:54 I don't want to put pressure on you, cyeoh so talk to mikal or russellb to ensure all is organized 00:36:31 I'd offer to help but I know zip about the topic 00:36:37 so Jon is a better choice 00:36:45 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 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 and leave it to a fairly open discussion. 00:38:07 I agree with that assessment 00:38:12 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 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 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 melwitt: not really - I'm just going to try to summarise the pain that I've seen through Nova API development 00:40:11 and hopefully through discussion in the session that will prompt people from other projects to bring up their experiences 00:40:19 yeah 00:40:44 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 melwitt: were you in hong kong at teh design summit there? 00:41:25 anteaya: yes, attended nearly all the nova design sessions in HK 00:41:35 melwitt: great 00:41:47 so the flow will be similar 00:41:59 and others will jump in if you need their input 00:43:01 ok so I think we'll be fine for that session then. 00:43:16 #topic input validation for names 00:43:28 I kind of threw this one on the agenda a couple of weeks ago and then didn't turn up :-) 00:43:40 you were busy 00:43:50 anteaya: a little distracted yes :-) 00:43:57 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 melwitt: I think it is best if you just decide now to do it 00:44:27 then you can start preparing 00:44:50 anteaya: okay, I can commit to it. thanks 00:44:59 go you, you will be great 00:45:05 sorry cyeoh 00:45:12 melwitt: cool - thanks! You will be great :-) 00:45:23 thanks anteaya and cyeoh :) 00:45:49 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 whether it be a keypair name, instance name etc 00:46:07 which is all very good for the future 00:46:30 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 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 eg do people really use leading spaces for instance names etc 00:47:16 cyeoh: ah, yes. we can not specify local chars(japanese, etc.) as server name on v2.1 and v3 API. 00:47:54 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 hopefully its a non-issue but I wanted to make sure everyone was aware of it. 00:48:45 cyeoh: yes, we need to do it if really necessary. 00:49:06 #topic api extension tasks 00:49:12 oomichi: I think this is yours? 00:49:19 cyeoh: yes 00:49:47 cyeoh: and you have already approved one topic just before this meeting, thanks:) 00:49:55 np - good work :-) 00:50:34 thanks 00:50:49 and we need to keep api extension names also consistent. 00:51:03 I will try it on Tempest side. 00:51:06 I agree we should keep the names consistent (it doesn't hurt at all) 00:51:21 with https://review.openstack.org/#/c/92010/ 00:51:50 should we do it on Nova unit tests ? or is it OK to do it on Tempest side? 00:52:12 oomichi: oh thats a good point - we could probably do it via unit tests 00:52:44 oh, OK. will try it on unit tests:) 00:52:45 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 thanks, that is all from me:) 00:53:37 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 #topic open discussion 00:54:10 anything anyone else wanted to talk about? 00:55:13 ok, thanks all for attending. Will talk to you all later! 00:55:21 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 melwitt: sure - I will put some notes together and email them to you 00:55:51 I can come up with things on my own but if you have anything, I'm glad to use it 00:56:00 cyeoh: thanks! 00:56:03 might not be today though but I will definitely send you some things :-) 00:56:17 cyeoh: great meeting! 00:56:33 cyeoh: okay, no rush. just sometime before the session :) appreciate it 00:56:52 cya all! 00:57:02 #endmeeting