12:00:03 <alex_xu> #startmeeting nova api
12:00:04 <openstack> Meeting started Tue Mar  8 12:00:03 2016 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:07 <openstack> The meeting name has been set to 'nova_api'
12:00:13 <alex_xu> who is here today?
12:00:24 <jichen> o/
12:00:35 <Kevin_Zheng> o/
12:00:39 <gmann_> hi
12:00:45 * johnthetubaguy lurking
12:01:33 <cdent> o/
12:01:36 <alex_xu> sorry, I didn't cleanup the agenda
12:01:50 <alex_xu> I think we can go to the open direct today
12:01:54 <alex_xu> #topic open
12:02:17 <alex_xu> #link https://bugs.launchpad.net/nova/+bug/1554440
12:02:17 <openstack> Launchpad bug 1554440 in OpenStack Compute (nova) "Show volume attachment exception does not looks good if server is in shelved_offloaded state" [Undecided,New] - Assigned to Ghanshyam Mann (ghanshyammann)
12:02:22 <alex_xu> gmann_: I think this is yours
12:02:25 <gmann_> ok
12:02:46 <gmann_> alex_xu: yea actually while implementing microversion tests 2.20 in tempest i saw this issue
12:03:13 <alex_xu> gmann_: so good we have microversion test in tempest now
12:03:19 <gmann_> I wanted to confirm 2 thing- 1. 'device' in volume attachments can be null any time?
12:03:36 <gmann_> alex_xu: sdague yea i updated patch https://review.openstack.org/#/c/258391/24
12:03:56 <johnthetubaguy> so device has lots of issues, as its only really a guess
12:03:57 <sdague> gmann_: I'll put that on my review list
12:04:14 <gmann_> sdague: Thanks
12:04:28 <gmann_> sdague: also bases patches, hanging long
12:04:39 <gmann_> those are for putting all microversion stuff in /lib
12:05:03 <allen_gao> sdague: would you look at this ? https://review.openstack.org/#/c/289822/
12:05:15 <gmann_> sdague: alex_xu any time mountppoint can be null - https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L223
12:05:44 <alex_xu> allen_gao: would you mind wait a minutes, let's finish gmann_'s agenda first
12:05:47 <gmann_> sdague: alex_xu because in tempest, we expect 'device' to be always present in response
12:06:11 <allen_gao> alex_xu: sorry
12:06:11 <johnthetubaguy> so honestly, I think both are wrong
12:06:13 <johnthetubaguy> kinda
12:06:17 <gmann_> sdague: I saw those for shelved offload case
12:06:26 <alex_xu> allen_gao: no worries :)
12:06:32 <johnthetubaguy> the API should really have some sort of "empty" value
12:06:38 <johnthetubaguy> but that is a new microversion
12:06:51 <johnthetubaguy> so the tempest test should make that optional, in the mean time
12:06:57 <johnthetubaguy> ... I think
12:07:13 <gmann_> johnthetubaguy: but other than shelved offload state, can it be for any other state?
12:07:46 <gmann_> for v2.1 tempest expect it as mandatory and non none
12:07:48 <tojuvone> hi, I am here. as of compute API docs
12:08:04 <gmann_> while doing for v2.20 testing i got doubt on those
12:08:19 <johnthetubaguy> gmann_: I suspect also during the attach, but I am not sure
12:08:22 <gmann_> from nova code those can be absent or None but do not know scenario
12:09:35 <gmann_> #link https://github.com/openstack/tempest/blob/master/tempest/lib/api_schema/response/compute/v2_1/servers.py#L270-L275
12:09:52 <johnthetubaguy> seems like device is optional: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3132
12:10:32 <johnthetubaguy> yeah, device is optional in the API
12:10:32 <johnthetubaguy> http://developer.openstack.org/api-ref-compute-v2.1.html#attachVolume
12:10:39 <johnthetubaguy> when you do attach
12:11:09 <gmann_> johnthetubaguy: yea and for virt nova does not honor eve if that is passed
12:11:32 <gmann_> johnthetubaguy: but will it be optional in response too, i think while booting instance it gets mounted
12:11:41 <johnthetubaguy> yeah, that
12:12:25 <johnthetubaguy> so I think its optional in the API, how we display that, is probably bad
12:12:35 <johnthetubaguy> not sure if that helps
12:12:50 <gmann_> humm
12:13:25 <gmann_> sdague: johnthetubaguy in that case, we might need to make this optional in tempest schema validation too
12:13:28 <johnthetubaguy> sounds like the tempest tests are wrong here, and the API is badly designed, as it shouldn't really hide the device like that
12:13:42 <gmann_> yea
12:13:46 <johnthetubaguy> yep, I think thats what I am saying here, needs to be optional
12:14:06 <gmann_> johnthetubaguy: ok, Thanks i will change that
12:14:06 <sdague> gmann_: sure, the schemas in tempest were best effort by oomichi, they weren't official from nova
12:14:15 <sdague> they very well could be wrong
12:14:22 <gmann_> sdague: yea
12:14:34 <gmann_> sdague: johnthetubaguy alex_xu second issue is  - https://bugs.launchpad.net/nova/+bug/1554440
12:14:34 <openstack> Launchpad bug 1554440 in OpenStack Compute (nova) "Show volume attachment exception does not looks good if server is in shelved_offloaded state" [High,Triaged] - Assigned to Ghanshyam Mann (ghanshyammann)
12:14:40 <gmann_> not sure though bug or ok
12:15:15 <gmann_> for shelved offload state, mount point will always be none and show attachment trow exception Not Found
12:15:32 <gmann_> #link https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L289
12:15:52 <johnthetubaguy> I think we should return the attachment
12:15:57 <gmann_> at least for shelved offload it should just ignore mount point and show response
12:16:13 <johnthetubaguy> logically the volume is "attached", just the device is missing as its not yet been physically attached
12:16:35 <johnthetubaguy> its bad to have list inconsistent
12:16:55 <alex_xu> so let return None for no mount point?
12:16:55 <gmann_> yea, on unselve that will be attached
12:17:17 <gmann_> alex_xu: yea None or just not add like list
12:17:20 <johnthetubaguy> you want it to appear, to check your API call to attach "happened" I think
12:17:41 <johnthetubaguy> yeah, it should match the list operation, for now, I think
12:17:51 <alex_xu> +1
12:18:01 <johnthetubaguy> this feels like a bug fix, rather than a microversion, but it feels a little boarderline
12:18:18 <alex_xu> I'm ok without microversion
12:18:24 <gmann_> johnthetubaguy: +1 for as bug fix
12:18:55 <gmann_> and that fix for all version i mean not just for v2.20 right?
12:19:25 <gmann_> i mean like list, if no mount point then just do not include 'Device'
12:19:35 <alex_xu> I'm also think of only fix for v2.20, that sounds like more safe, if we think this is borderline
12:20:22 <johnthetubaguy> include device? I thought we were talking about stopping the 404?
12:20:46 <johnthetubaguy> ah, sorry, missread I think
12:20:58 <alex_xu> johnthetubaguy: yea, stop the 404 in 2.20
12:21:03 <gmann_> johnthetubaguy: not include if None same as list
12:21:20 <gmann_> alex_xu: but for older version also it is bit inconsistent
12:21:39 <gmann_> it is 404 -> 200, should not be issue
12:22:26 <johnthetubaguy> that sounds reasonable to me, easier once we have the change up, and think through it
12:23:03 <alex_xu> johnthetubaguy: you mean fix it in all versions?
12:23:04 <gmann_> johnthetubaguy: sounds good. I will put patch up early tomorrow. then we can discuss more
12:24:38 <johnthetubaguy> possibly fix in all versions, I think its easier to get the code up so we can see the impact
12:24:52 <alex_xu> johnthetubaguy: ok, cool
12:24:58 <alex_xu> so let's move on
12:25:03 <gmann_> yea
12:25:17 <alex_xu> allen_gao: I think your problem resolved, sdague already +2 your patch
12:26:11 <alex_xu> tojuvone: your turn
12:26:26 <tojuvone> #link https://bugs.launchpad.net/openstack-api-site/+bug/1554052
12:26:26 <openstack> Launchpad bug 1554052 in openstack-api-site "os-services missing from compute API v2.1" [Medium,Confirmed] - Assigned to Tomi Juvonen (tomi-juvonen-q)
12:27:13 <tojuvone> So, os-services missing and also was wondering how it is with microversions. Should those api changes also be there?
12:27:39 <johnthetubaguy> so right now, that doc is only documenting v2.1 (the base version), I think
12:27:39 <alex_xu> tojuvone: sorry, we don't support microversion in the api-site yet
12:27:50 <johnthetubaguy> yeah, what alex_xu said
12:28:07 <alex_xu> yea, I think we try to figure out in newton, maybe we will have swagger support
12:28:14 <johnthetubaguy> now, os-services, was that there before
12:28:21 <tojuvone> ok, hope there is nothing else then missing than this os-services, I can continue to look this
12:28:22 <johnthetubaguy> alex_xu: we really, really have to fix that next cycle
12:28:46 <johnthetubaguy> tojuvone: I though we added a load back in there, did this get dropped somehow?
12:28:52 <alex_xu> johnthetubaguy: yea, otherwise we got another big gap between doc and api
12:28:52 <johnthetubaguy> thought^
12:29:22 <alex_xu> yea, for now, I think we just need load it back
12:29:49 <tojuvone> I found some work from jichenjc, maybe I can contact him (where I think this was removed)
12:30:08 <gmann_> yea, may be misplaced during some updates :)
12:30:40 <tojuvone> ok, well I look it and good to know the microversion stuff
12:30:43 <johnthetubaguy> I think annegentle pinged my about some removals
12:30:45 <alex_xu> tojuvone: yea, jichen help a lot of on that
12:30:46 <jichen> tojuvone:I am here
12:30:59 <johnthetubaguy> we should really make sure there are no removals vs v2.0
12:31:19 <johnthetubaguy> I did go back a few months back and double check everything, and added a few back in
12:31:25 <johnthetubaguy> seems we somehow lost some
12:31:39 <jichen> tojuvone: I didn't remove service related , as far as I remember ..
12:32:30 <allen_gao> alex_xu: yea, thank you ;)
12:32:30 <johnthetubaguy> so I seem some stuff in here:
12:32:31 <johnthetubaguy> https://github.com/openstack/api-site/commit/2daa7d811b59020c0c5e16137a1f65ec5fa26b73
12:32:57 <johnthetubaguy> this one totally makes sense: https://github.com/openstack/api-site/commit/5feaeccde67655db32e64ab408b2a108fbfe5824
12:33:05 <johnthetubaguy> so I guess its where we had added microversion stuff in?
12:33:18 <johnthetubaguy> those removals seem correct
12:33:40 <tojuvone> johnthetubaguy: yes, that is microversion
12:33:47 <jichen> oops, yes, that's made by me
12:33:52 <jichen> sorry, I forgot this
12:34:04 <alex_xu> that won't remove all the os-service doc I guess?
12:34:05 <johnthetubaguy> jichen: no worries, you have been very busy :)
12:34:25 <johnthetubaguy> alex_xu: it looks like the existing things are still there, but I am not 100% sure
12:34:25 <tojuvone> but then there was change on ch_compute-v2.1.xml
12:34:32 <johnthetubaguy> ah...
12:34:36 <johnthetubaguy> so that sounds bad
12:35:09 <tojuvone> yes, I think os-services-v2.1.wadl is good
12:35:20 <alex_xu> emm...ok
12:35:29 <alex_xu> anyway let's add os-services back
12:35:35 <gmann_> yea
12:35:39 <tojuvone> then some api sample was missing after I tried to fix ch_compute-v2.1.xml
12:35:51 <tojuvone> yep, no need to go further here ;)
12:35:52 <alex_xu> tojuvone: if you still have trouble, free to ping me
12:36:12 <alex_xu> so I think we can move on
12:36:17 * gmann_ curious about api sample missing
12:36:43 <alex_xu> Kevin_Zheng: you have think want to discuss right?
12:36:49 <Kevin_Zheng> yes
12:36:59 <Kevin_Zheng> I want to raise a topic
12:37:03 * alex_xu is typing slow by unstable network
12:37:11 <Kevin_Zheng> http://developer.openstack.org/api-ref-compute-v2.1.html#createServer
12:37:19 <johnthetubaguy> tojuvone: alex_xu: sounds like we all agree on the direction for the docs, so thats the main bits, I guess
12:37:31 <alex_xu> johnthetubaguy: yup
12:37:39 <tojuvone> johnthetubaguy: yep
12:37:47 <Kevin_Zheng> here, we clarified twice about the length limit of injected file content
12:38:02 <Kevin_Zheng> The maximum limit refers to the number of bytes in the decoded data and not to the number of characters in the encoded data.
12:38:27 <Kevin_Zheng> and The file path and contents, text only, to inject into the server at launch. The maximum size of the file path data is 255 bytes. The maximum limit is The number of allowed bytes in the decoded, rather than encoded, data.
12:38:46 <Kevin_Zheng> the second one is in the chart of create instance parameters
12:39:03 <Kevin_Zheng> but in the code: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/api.py#n270
12:39:19 <Kevin_Zheng> we are actually checking the base64 encoded data directly
12:39:43 <Kevin_Zheng> data length will grow after base64 encode
12:40:09 <Kevin_Zheng> for example 7680 bytes will grow to 10240
12:40:44 <Kevin_Zheng> user will have to determain the length of data after encode
12:40:51 <Kevin_Zheng> and it is inconstant
12:41:00 <Kevin_Zheng> What should we do?
12:41:11 <johnthetubaguy> I think the max has to be on what is input to the API, I think, isn't that correct here?
12:41:14 <Kevin_Zheng> sorry inconsistant
12:41:55 <Kevin_Zheng> yes it is, but the doc writes it should be decoded data
12:42:25 <Kevin_Zheng> and it will be harder for user to determain the data length after encode
12:43:18 <johnthetubaguy> so what does the user pass to the API, its the encoded data, I thought?
12:43:22 <johnthetubaguy> or is that wrong?
12:43:35 <Kevin_Zheng> yes user should pass encoded data
12:43:38 <alex_xu> yes, user padd to the API with encoded data
12:43:45 <alex_xu> s/padd/pass...
12:43:53 <Kevin_Zheng> but for example, using novaclient,
12:44:05 <Kevin_Zheng> user pass a file to client
12:44:12 <Kevin_Zheng> client will encode the content
12:44:33 <johnthetubaguy> yes, agreed
12:44:40 <Kevin_Zheng> user will not know the length after encode
12:44:40 <alex_xu> I guess Kevin_Zheng's point is from end-user which use UI or CLI
12:44:55 <johnthetubaguy> its the rest API point of view that should be taken here
12:45:08 <johnthetubaguy> although I am wondering how this has been "wrong" for so long
12:45:51 <Kevin_Zheng> I think it is not user friendly to let them calculate the encoded length
12:46:09 <johnthetubaguy> so, the question here is what does the API actually do today
12:46:11 <Kevin_Zheng> as show the file size will be pretty simple
12:46:27 <johnthetubaguy> now, we might want to change that, but that is a breaking API change
12:46:33 <Kevin_Zheng> it checkes the content directly
12:46:53 <alex_xu> johnthetubaguy: agree
12:47:06 <Kevin_Zheng> yes, as the current allowed size is smaller than the actual limit
12:47:33 <Kevin_Zheng> the current existed users will not be affected
12:48:05 <alex_xu> no, if user talk with two clouds with fix or without fix, this is breaking without microversion
12:48:15 <johnthetubaguy> right
12:48:32 <gmann_> yea, interoperability can be issue
12:48:37 <johnthetubaguy> well, actually, its a bit more odd
12:48:43 <Kevin_Zheng> so, should we fix this?
12:48:45 <johnthetubaguy> you need to list your quotas to work out what is allowed
12:48:55 <johnthetubaguy> Kevin_Zheng: we should fix the docs, so they are correct, for sure
12:48:57 <Kevin_Zheng> adding microversion
12:49:16 <Kevin_Zheng> so we fix doc, not the code?
12:49:27 <johnthetubaguy> step 1: fix docs
12:49:28 <Kevin_Zheng> but it will be less user friendly
12:49:48 <johnthetubaguy> step 2: decide if we want to change newer microversions to be more friendly
12:49:57 <johnthetubaguy> noting the old behaviour can't chnage
12:49:57 <alex_xu> +1
12:50:26 <Kevin_Zheng> so change the doc to encoded data?
12:50:29 <johnthetubaguy> we can have a newton spec to discuss this
12:50:42 <johnthetubaguy> Kevin_Zheng: make sure the docs match the current/existing behaviour, yes
12:50:48 <Kevin_Zheng> OK, I will do that
12:50:55 <johnthetubaguy> we should really be sure to add some tests around this
12:51:11 <Kevin_Zheng> Hmm
12:51:12 <johnthetubaguy> I do worry if we changed this behaviour by accident at some point
12:51:37 <alex_xu> yes
12:51:55 <alex_xu> Kevin_Zheng: is this ok for you?
12:52:06 <Kevin_Zheng> yes, I will do it
12:52:12 <alex_xu> Kevin_Zheng: cool, thanks
12:52:42 <Kevin_Zheng> Another question, can we add the support for "locked" filter when list servers?
12:53:03 <Kevin_Zheng> currently we can only got the information using show API
12:53:23 <Kevin_Zheng> it will take forever to check all instances
12:53:42 <alex_xu> Kevin_Zheng: sounds ok, but I think we can decided that by spec
12:53:55 <Kevin_Zheng> Hm, sure
12:54:01 <johnthetubaguy> don't you get that with the show details api?
12:54:19 <gmann_> Kevin_Zheng: show detail shows that in v2.9
12:54:27 <johnthetubaguy> I am wondering why we need it int the regular list
12:54:41 <johnthetubaguy> gmann_: ah...
12:54:41 <Kevin_Zheng> I will check that
12:54:59 <johnthetubaguy> yeah, it feels like being in the detail list is the correct thing for locked
12:55:01 <gmann_> i feel list should not show all
12:55:17 <Kevin_Zheng> I mean we add a filter
12:55:19 <gmann_> johnthetubaguy: yea it is in show and detail list both
12:55:28 <Kevin_Zheng> to filter out all the locked instances
12:55:32 <johnthetubaguy> gmann_: yeah, that seems correct
12:55:36 <Kevin_Zheng> like deleted
12:55:53 <Kevin_Zheng> I will check that
12:56:10 <johnthetubaguy> Kevin_Zheng: a filter seems OK, its worth a spec to add that in a microversion
12:56:16 <gmann_> cannot that be done with regex, not sure though how exact that will be
12:56:52 <Kevin_Zheng> johnthetubaguy: hm, I will do that
12:56:58 <Kevin_Zheng> Thanks all
12:57:01 <alex_xu> emm...sorry guys, 4 mins left. actually I want to talk about meeting time change
12:57:26 <alex_xu> just oomichi can't make this meeting, due to the meeting is 4:00 am for him
12:57:37 <gmann_> alex_xu: ohh
12:58:03 <johnthetubaguy> it does feel like we should alternate meeting times
12:58:04 <alex_xu> so is there any propose for the time, I check the date, I founds really hard find one to propose
12:58:13 <johnthetubaguy> maybe its worth a quick doodle poll, or similar?
12:58:18 <alex_xu> johnthetubaguy: emm...that also good idea
12:58:22 <cdent> doodle++
12:58:23 <gmann_> yea
12:58:45 <alex_xu> johnthetubaguy: yea, just found really hard find out a initial propose time :)
12:58:45 <johnthetubaguy> maybe pick four times (possibly just think about mirroring the nova meeting times on a different day)
12:59:23 <alex_xu> ok, let me try again, I will take care of this.
12:59:30 <johnthetubaguy> alex_xu: if it helps its 1pm for me right now
12:59:52 <johnthetubaguy> alex_xu: I can try help with ideas, ping me if I can help
13:00:14 <alex_xu> johnthetubaguy: not sure it is ok for gmann_
13:00:18 <alex_xu> johnthetubaguy: thanks :)
13:00:24 <alex_xu> soorry, it's time to close the meeting
13:00:26 <gmann_> alex_xu: need to check JST
13:00:50 <alex_xu> anyway, thanks all!
13:00:52 <alex_xu> #endmeeting