12:00:04 #startmeeting nova api 12:00:05 Meeting started Tue Sep 8 12:00:04 2015 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:08 The meeting name has been set to 'nova_api' 12:00:13 who is here today? 12:00:18 o/ 12:00:25 o/ 12:00:47 o/ 12:00:56 hello everyone 12:01:05 let's start the meeting 12:01:07 #topic actions from last meeting 12:01:17 sdague to write up test plan for v2.x nova, alex_xu and gmann_ will work on patches 12:01:33 actually sdague did all the things :) 12:01:41 yea 12:01:41 #link https://review.openstack.org/#/c/219370/ 12:01:46 #link https://review.openstack.org/#/c/219347/ 12:02:09 all of that are merged 12:02:18 there is last one from gmann_ 12:02:25 #link https://review.openstack.org/#/c/219553/ 12:02:44 I think this is all for gate 12:03:04 #link https://review.openstack.org/#/c/219555/ 12:03:33 gmann_: thanks 12:03:59 I guess this is all for v2 api on gate 12:04:27 sdague: ^ are you around? is there anything more on gate for v2 api? 12:04:30 alex_xu: sdague : do we need v21 compatible job as experimental on tempest as discussed on https://review.openstack.org/#/c/219370/ 12:04:56 v21 compatible is now the default run right? 12:05:06 given the paste-api.ini changes 12:05:08 johnthetubaguy: v21 is default 12:05:09 yea 12:05:19 hmm, so whats on the v21 jobs? 12:05:37 johnthetubaguy: /v21 service catalog 12:05:46 check-tempest-dsvm-full vs check-tempest-dsvm-nova-v21-full 12:05:53 and each job for /v2 and v21 compatible 12:05:58 o/ 12:06:05 I thought the first would fire at /v2.0 and the second fires at /v2.1? 12:06:19 johnthetubaguy: check-tempest-dsvm-nova-v21-full will be removed in https://review.openstack.org/#/c/219553/ 12:06:22 what we are missing now are tests for leagacy_v2 code I thought? 12:06:37 yea, I think so 12:06:47 johnthetubaguy: so check-tempest-dsvm-full is now pointing at /v2.1 12:06:52 johnthetubaguy: for legacy v2 code we have one new job 12:06:59 because devstack compute SC entry is now pointing at /v2.1 12:07:09 there is a compute_legacy SC entry 12:07:17 gate-tempest-dsvm-nova-v20-api 12:07:17 sdague: OK, gotcha 12:07:17 which is the /v2.0 endpoint 12:07:23 there are 2 jobs testing it 12:08:05 what is for v2.1 legacy compat mode? 12:08:07 gate-tempest-dsvm-nova-v20-api 12:08:19 ah, they on the experimental queue I guess 12:08:20 which is v2.0 on v2.1 12:08:25 gate-tempest-dsvm-nova-v20-api-legacy 12:08:29 v2.0 on old v2.0 12:08:37 johnthetubaguy: no, they are in check queue, non-voting 12:08:38 ah, yea 12:08:44 johnthetubaguy: they are on check pipeline 12:08:45 ah, so thats nice and simple, cool 12:08:45 they only run the compute api tempest tests 12:09:00 so we are good, right? 12:09:03 sdague: ah, so I am looking at runs that are too old, thinking about it 12:09:12 alex_xu: sounds perfect to me 12:09:12 johnthetubaguy: yeh, they landed late last week 12:09:24 my intent is to look at the stats on those today 12:09:33 and if the pass rate is high enough, make them voting 12:09:41 sweet 12:09:43 cool 12:09:47 sdague: do we need v21 comap job as experimental on tempest? 12:10:02 sdague: +1 to make them voting 12:10:10 gmann_: yeh, we should probably put both those jobs in tempest experimental as well 12:10:24 sdague: yea 12:10:26 gmann_: you want to post the patch for that? 12:10:37 sdague: yea, i can post tomorrow early 12:11:37 #action gmann_ post patch put v2.1 compat and v2 legacy jobs as experimental 12:11:44 alex_xu: thanks 12:11:52 gmann_: np 12:11:58 let's move on 12:12:01 edleafe will update https://review.openstack.org/#/c/217727/ 12:12:11 for this, let's jump to next topic directly 12:12:20 #topic v2.0 on v2.1 12:12:30 There are some patches we need discussion, and all of them are about whether fix it for v2.1. Let's talk about them one by one 12:12:40 #link https://review.openstack.org/#/c/217727/ 12:12:59 I prefer fix it for v2.1 also. Otherwise when user switch to v2.1 the functionality of support out-of-tree filters is broken. 12:13:13 ken'ichi change his mind also, he removed -1 12:13:35 I haven't caught up on the discussion on that patchset yet. 12:13:47 I'm recovering from a long US weekend. :) 12:13:50 right, I thought we were generally agreed to let through scheduler filters 12:13:57 edleafe: the argument is more about whether we fix it in the v2.1 API 12:14:06 alex_xu: oh, so we are not going with runtime discovery for hint? 12:14:30 sdague: for v2.1 also 12:14:32 gmann_: we still need to get to discovery, but if we don't let this through it means that rax won't use v2.1 12:14:36 which I'd like to avoid 12:14:39 gmann_: we need think that more. 12:14:47 they need custom scheduler filters 12:15:13 we certainly need some for the v2.0 compatibility mode 12:15:19 sdague: humm, yea that true 12:15:34 yeh, but I also think that it's fine to be pragmatic on this one 12:15:35 we could just hack the validation logic, but thats pretty aweful 12:15:40 to discover which hints enabled in the deployement, shouldn't be done by the json-schema. I think that is capabilites discovery. json-schema is part of our api contract 12:16:05 laski brought it up a bunch of times as a real issue, and I'm fine with that 12:16:21 ohk 12:16:26 so I'm conceptually +2 on https://review.openstack.org/#/c/217727/ - though I haven't reviewed the patch in detail 12:16:37 yeah, so we need a "proper" way to do all this, but we don't have one right now, so it feels like 217727 is the best way forward 12:16:54 agreed, especially if it means we'll get v2.1 deployed at RAX 12:17:09 I'm happy with that trade off 12:17:09 cool, looks like we get agreement 12:17:18 +1 from me conceptually 12:17:25 let's move on 12:17:27 #link https://bugs.launchpad.net/nova/+bug/1491511 12:17:28 Launchpad bug 1491511 in OpenStack Compute (nova) "Behavior change with latest nova paste config" [Critical,In progress] - Assigned to Alex Xu (xuhj) 12:17:37 ok, for now looks good solution. 12:17:40 We have three patches for this bug. 12:17:46 #link https://review.openstack.org/#/c/220386/ 12:17:51 I think this is need fix for v2.1, otherwise the cell functionality is broken. 12:17:52 right, so this is the catch all of issues we are finding 12:18:12 (I have a new one, but its a separate issue) 12:18:18 #info https://review.openstack.org/#/c/220386/ - fixes for cell names - merged 12:18:31 sdague: i was just wondering if server name can be used as hostname like for DNS entry etc? 12:18:36 so we are goodfor this? 12:18:47 #link https://review.openstack.org/220279 12:18:52 gmann_: that's the next one 12:18:52 gmann_: you are talk about this ^ 12:19:23 yeh, so it does get coerced into a hostname in dnsmasq some times 12:19:32 sdague: yea 12:19:38 however, in v2.0 there was no checking 12:19:45 yeah, it does, but its primarily a display name 12:19:47 yea 12:19:54 so we are good for this in v2.1? 12:19:57 and the v2.1 schema doesn't guaruntee a working hostname 12:20:02 (updating the name doesn't change the hostname, for example, at least not usually) 12:20:08 johnthetubaguy: yea agree it is for display name 12:20:32 so I think there should be a follow on bug to make a function that tries to make a safe dns name out of it 12:20:46 for when it gets written to dnsmasq 12:20:58 sdague: I remember there is code take care of it 12:21:01 sdague: I think thats a good way to go (there is some stuff that trims the name somewhere, for windows) 12:21:09 alex_xu: not that I found 12:21:19 the only thing I found was it lowercasing things 12:21:27 * alex_xu find the link 12:21:34 hmm, maybe its inside the xenapi driver, oh dear 12:21:36 but it wasn't handling spaces or special characters 12:21:55 so seems like we need to just deal with spaces 12:21:59 #link https://github.com/openstack/nova/blob/master/nova/compute/api.py#L640 12:22:07 sdague: so you mean we allow server name as display name with relaxing much restriction on that and later something should make that a dns name out of it? 12:22:16 johnthetubaguy: there are a lot of other invalid characters in hostnames as well 12:22:22 sdague: +1 12:22:48 #link https://github.com/openstack/nova/blob/master/nova/utils.py#L774 12:22:53 The Internet standards (Requests for Comments) for protocols mandate that component hostname labels may contain only the ASCII letters 'a' through 'z' (in a case-insensitive manner), the digits '0' through '9', and the hyphen ('-'). The original specification of hostnames in RFC 952, mandated that labels could not start with a digit or with a hyphen, and must not end with a hyphen. However, a subsequent specification (RFC 1123) permitted hos 12:22:53 tname labels to start with digits. No other symbols, punctuation characters, or white space are permitted. 12:23:53 so I guess the consensus is merge the relax, and follow up with the above fix 12:24:11 alex_xu: that regex looks wrong, but lets take that offline 12:24:17 I'd like to see lots of unit tests for that 12:24:18 sdague: ok 12:24:25 +1 for the unit tests 12:24:28 johnthetubaguy: +1 12:24:43 #link #link https://review.openstack.org/220791 12:24:49 Another part of relax validation for server name, actually I found some api allow leading/trailing spaces in the name. 12:25:11 not sure we want to fix this, as the leading/trailing spaces is useless use-case 12:25:15 alex_xu: also, sanitize hostname is getting called in a weird place 12:25:37 sdague: actually it convert from the name 12:25:50 right, but it's changing the db entry 12:26:19 emm...yea, I didn't notice that 12:26:22 agree with you 12:26:37 so, how about we open a new bug for getting the hostname bit right 12:26:48 +1 12:26:54 alex_xu: can you open that bug? 12:26:58 sure 12:27:09 #action alex_xu open a bug for fix the hostname 12:27:14 thanks 12:27:18 np 12:27:40 so back to https://review.openstack.org/220791 12:27:55 whether we need fix ^ 12:28:05 alex_xu: that one I'm less sure, johnthetubaguy ? 12:28:16 alex_xu: what was the v2.0 behavior here? 12:28:58 yeah, we should match v2.0 I feel, although I haven't checked what that is 12:29:15 seems like we should strip the whitespace though, if we allow it 12:29:15 sdague: it was mix in v2.0, some resource allow and strip and some does not strip only allow 12:29:17 sdague: a little mess if you see the commit message, server and flavor allow leading/trailing spaces and strip spaces and not allow all spaces string, other api with name didn't strip and allow all spaces string 12:29:38 alex_xu: yea 12:29:45 so I would go for allow and strip for all of them, would that work? 12:30:08 johnthetubaguy: sdague: alex_xu : but do we need to do that for v2.1 also or only for v21 compatible mode? 12:30:15 johnthetubaguy: that means we fix the server and flavor, but still strict for other apis 12:30:39 alex_xu: how are the APIs restricted? you mean trailing whitespace is always ignored now? 12:30:41 gmann_: yea, that also a question 12:30:44 alex_xu: so if we allow and strip, do we need to go and clean up the data in the db for matching? 12:30:51 for the stuff that wasn't stripped before 12:30:57 johnthetubaguy: some of apis not, like aggregates 12:31:04 sdague: I am tempted to say no for that 12:31:08 I think allow and strip is probably right 12:31:13 alex_xu: I think I am OK with that 12:31:32 so this is ok for v2.1? 12:31:48 I am tempted to say yes, but it doesn't feel very clear cut 12:31:54 alex_xu: i feel we should have clean way for v2.1 means do not allow 12:32:31 so for the compat, we defiantly need strip and accept 12:32:38 how bad would it be to allow in v2.0 compat mode and be strict in v2.1 12:32:43 in terms of code? 12:33:09 this patch can answer you https://review.openstack.org/221129 12:33:12 so yeah, maintain our strictness for v2.1, I am happier with that approach 12:33:17 sdague: you might need 2 set of schema looks like but may be sone common place change for name format 12:33:46 alex_xu: so it's not just validation right, it's also a transform to do the strip 12:34:14 sdague: indeed, we still need python code to strip 12:34:14 we'll still need the transform right? 12:34:31 I guess we can always to the strip, and the schema stops that doing anything in some cases 12:34:34 can that be done as a decorator to transform 12:34:44 I think not 12:34:45 johnthetubaguy: oh, that's true 12:35:09 sdague: yeah, it just came to me, and suddenly felt more palatable 12:35:17 alex_xu: yeh, so conceptual +2 on kenichi's patch, I'll review after meeting 12:35:25 sdague: cool 12:35:31 also, he needs to not put these things in WF-1 :) 12:35:53 emm...that only can catch him tomorrow 12:36:16 #action everyone review kenichi's json schema for 2.0 patch - https://review.openstack.org/221129 as a way to enforce differently for v2.0 12:36:23 at line 76 there is terrible regexp also https://review.openstack.org/#/c/220791/1/nova/api/validation/parameter_types.py 12:36:53 yep 12:37:05 * alex_xu hate regexp 12:37:21 honestly, these things are getting to the point where they should probably be enforced with a gramar and not regex 12:37:21 * edleafe loves good regexp 12:37:43 to be clear https://review.openstack.org/220279 fix for v2 and v2.1, https://review.openstack.org/220791 only for v2? 12:37:49 sdague: its getting dam close 12:37:57 * bauzas waves very late 12:37:58 sdague: yea 12:38:21 * bauzas scrolls back 12:38:26 * alex_xu waves to bauzas 12:38:50 sdague: yea 12:39:05 anyway, that's for next cycle 12:39:24 ok, so we seem clear on all these patches in concept? 12:39:36 now it's just getting them into shape and landed, right 12:39:46 sdague: yea 12:39:51 cool 12:40:11 let's move... 12:40:13 alex_xu: if you remove your -1 on this - https://review.openstack.org/#/c/220279 - I'll approve 12:40:38 sdague: done! 12:41:04 did we have a previous patch that bauzas was -1 one on, about the scheduler hints? 12:41:28 johnthetubaguy: I left -1 just for a placeholder until we have a convo 12:41:42 yeh, as we went through that already, lets cycle on -nova after 12:41:48 we already have convo for that... 12:41:48 johnthetubaguy: but looking at the discussion above, is there a consensus yet ? 12:41:59 okay, move on to -nova then 12:42:08 #link https://bugs.launchpad.net/python-novaclient/+bug/1491325 12:42:09 Launchpad bug 1491325 in OpenStack Compute (nova) "nova api v2.1 does not allow to use autodetection of volume device path" [Critical,Fix committed] - Assigned to Davanum Srinivas (DIMS) (dims-v) 12:42:09 when the meeting is ended 12:42:13 this already fixed 12:42:23 so we are good for this? 12:42:26 alex_xu: right, we fixed it in both nova and novaclient 12:42:35 sdague: cool 12:42:45 I responded with a long email to gmann_ on the list this morning about why we did it they way we did 12:42:58 hopefully that has enough detail 12:43:02 sdague: ohk, i will read your reply, i was on vacation today 12:43:09 sdague: Thanks :) 12:43:14 * alex_xu will read the email 12:43:25 I think that is all for v2 on v2.1. 12:43:37 so I have a python-novaclient bug 12:43:40 its a bit related 12:43:48 its described here: https://review.openstack.org/#/c/221222/ 12:44:00 https://launchpad.net/bugs/1493207 12:44:01 Launchpad bug 1493205 in OpenStack Dashboard (Horizon) "duplicate for #1493207 Create Keypair failed on latest DevStack" [Undecided,New] - Assigned to Chung Chih, Hung (lyanchih) 12:44:01 right, the fact that the API isn't defaulting to v2.0 if not specified? 12:44:04 did we discussed of https://bugs.launchpad.net/nova/+bug/1492925 ? 12:44:05 Launchpad bug 1492925 in OpenStack Compute (nova) "Lack of API schema definition for different cell filter" [Undecided,In progress] - Assigned to Ken'ichi Ohmichi (oomichi) 12:44:28 bauzas: yeh, we hit the cells bit already 12:44:31 johnthetubaguy: my bad, you're first 12:44:41 we said the novaclient default to latest 12:44:46 sdague: coolness, thanks 12:44:46 alex_xu: the CLI 12:44:47 so python-novaclient seems to default in a broken way 12:45:07 the client defaults to find the max version, but not sending version headers 12:45:08 the API should default back to oldest 12:45:09 sdague: oops, that bug about api? 12:45:14 alex_xu: yeh 12:45:25 it should really default to the min version 12:45:28 I remember I coding like that 12:45:41 johnthetubaguy: agree 12:45:52 johnthetubaguy: yeh, so it seems like it was just only 1/2 implemented 12:46:07 also, that should be easy enough to test with the functional tests once it's right 12:46:15 so the unit tests would have found this 12:46:23 yea 12:46:26 but they were written so it was avoided 12:46:30 johnthetubaguy: do you need me take care that patch? 12:46:31 heh 12:46:45 this reproduces the failure: https://review.openstack.org/#/c/221222/2/novaclient/tests/unit/v2/test_keypairs.py,cm 12:47:42 been fighting to find a fix 12:48:31 cool 12:49:05 so that's all? 12:49:10 anyways, seems like we have consensus on the correct behaviour 12:49:18 yea 12:49:24 I might need a hand with the patch if this next attempt doesn't work 12:49:43 johnthetubaguy: yea, I can help 12:49:47 me too 12:50:15 OK, cool, just know I need to get back to reviews again 12:50:29 ok, so is there a way to target python-novaclient bugs? 12:50:30 thats all, thanks for the offers 12:50:37 it was duped, so the new bug is - https://bugs.launchpad.net/python-novaclient/+bug/1493205 12:50:39 Launchpad bug 1493205 in python-novaclient "Create Keypair failed on latest DevStack" [Undecided,New] 12:50:41 ok, so johnthetubaguy you can free to catch me or edleafe when you need a hand 12:50:47 sdague: good point, I guess not 12:51:20 ok, well so be it 12:51:31 I marked it critical so hopefully it doesn't get lost 12:51:44 sdague: cool, thanks 12:52:10 anything more for v2.1? 12:52:39 ok, so let's move on 12:52:47 #topic Removal of v3 naming from source tree 12:53:09 edleafe: sorry I didn't follow that, any patch you still have? 12:53:29 yes - looks like https://review.openstack.org/#/c/214290/ needs a rebase 12:53:38 I can take care of that after the meeting 12:53:44 edleafe: if you could take a look at this for me, that would be cool: https://review.openstack.org/#/c/221222/ 12:53:55 and a few small things for https://review.openstack.org/#/c/214311 12:54:15 johnthetubaguy: will do 12:54:38 * edleafe will need to make coffee first 12:55:19 edleafe: agreed, I just -1ed my patch with why I don't like it, but it does seem to pass unit tests now 12:55:24 https://review.openstack.org/#/c/214311 looks like more important, it correct some log message, they are user faced thing 12:56:14 so just for this we just need update patch and review, right? 12:56:16 edleafe: yeh, I think the -1 on 214311 should be easy fix 12:56:21 so the above patch is currently breaking horrizon 12:56:30 and probably lots of other users 12:56:44 johnthetubaguy: which one? 12:56:45 I mean: https://review.openstack.org/#/c/221222 when I say above 12:57:00 ohk 12:57:02 johnthetubaguy: +1 this is the far most critical 12:57:09 yea 12:57:30 johnthetubaguy: yeh I've got some paper work to do today, but I'll take a look at that patch 12:57:43 and see if I can sort out a working rev 12:57:50 cool, just wanted to make sure we all understood the impact there 12:57:58 and make mriedem do more novaclient releases 12:58:07 I did give horizon folks I was talking to a hack, if needed 12:58:20 right, we should fix it, it's going to break other people as well 12:58:23 but we have to fix it either way 12:58:30 sdague: yeah, +1 12:58:41 agree 12:58:45 so... next cycle, can we release novaclient every monday? 12:58:56 because part of this issue is we had 4 months of changes all drop at once 12:59:13 4 months... 12:59:14 sdague: nice point to catch those early 12:59:15 sdague: yeah, or every other, that would totally make sense 12:59:16 +1 to more frequent releases 12:59:18 and I'd much rather flush out issues faster 12:59:32 I think a weekly release for a library should be fine 12:59:34 sdague: I mean we should have done every milestone at a minimum, but it just didn't happen 12:59:38 yep 12:59:55 jump to open directly, avoid somebody need help 12:59:57 #topic open 13:00:02 I had a question 13:00:05 but 20 secs left 13:00:11 so moving on to -nova instead 13:00:14 yea... 13:00:19 honestly, I was waiting for the microversion support to drop really, and that was recent, we should do time bound releases there 13:00:23 so...thanks all! 13:00:32 thanks alex_xu! 13:00:33 thanks alex_xu 13:00:35 #endmeeting