Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-09
23:55:45 mriedem -HEAD
23:55:55 mriedem danpb wrote that quite a while ago
23:56:17 mriedem https://github.com/openstack/nova/blob/master/tools/flake8wrap.sh#L12
23:56:18 melwitt oh, hm
23:56:33 mriedem i never run full pep8 on nova anymore
23:56:36 melwitt wow. thanks
23:57:30 efried Second that.
#openstack-nova - 2017-03-10
00:00:14 efried Now if he could just do that for pyXX...
00:01:33 mriedem you don't want it for py27
00:01:53 efried mriedem It would have to be really, really smart.
00:02:05 mriedem this just cycled in https://www.youtube.com/watch?v=Lrle0x_DHBM so things are looking up
00:02:12 efried In my case, I'm getting away with -- nova.tests.unit.virt.powervm
00:05:17 cburgess Oh wow thats soo cool.
00:08:00 mriedem cburgess: -HEAD or earth, wind and fire? :)
00:08:11 cburgess head
00:08:22 melwitt both, duh
00:11:30 mriedem here come dem fixes
00:11:40 openstackgerrit Matt Riedemann proposed openstack/nova master: Decrement quota when deleting an instance in cell0 https://review.openstack.org/443395
00:11:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix missing instance.delete notification https://review.openstack.org/437222
00:11:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Temporarily untarget context when deleting from cell0 https://review.openstack.org/443403
00:11:42 openstack bug 1670627 in OpenStack Compute (nova) "quota is always in-use after delete the ERROR instances " [Critical,In progress] https://launchpad.net/bugs/1670627 - Assigned to Matt Riedemann (mriedem)
00:11:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Add regression test for bug 1670627 https://review.openstack.org/443745
00:17:59 openstackgerrit Eric Fried proposed openstack/nova master: WIP: PowerVM Driver: SSP emphemeral disk support https://review.openstack.org/443189
00:28:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Decrement quota when deleting an instance in cell0 https://review.openstack.org/443395
00:28:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Temporarily untarget context when deleting from cell0 https://review.openstack.org/443403
00:33:12 melwitt dansmith: I added a question on the consoleauth upcall patch https://review.openstack.org/#/c/415922/7/nova/compute/api.py@3469 if you have any thoughts
01:41:57 openstackgerrit gengchc2 proposed openstack/nova-specs master: Fix typos in server-count-api.rst,etc https://review.openstack.org/413916
02:28:49 openstackgerrit Alex Xu proposed openstack/nova-specs master: Fix the typo in the resource provider traits spec https://review.openstack.org/444065
02:29:10 alex_xu dansmith: thanks for the review, and the typo fix ^
02:51:48 Qiming alex_xu, morning
02:51:58 alex_xu Qiming: morning too
02:52:18 Qiming alex_xu, about the returning of user_data in OS-EXT-SERV-ATTR:user_data
02:52:31 alex_xu Qiming: yea
02:52:47 Qiming alex_xu, why didn't we just return it in user_data?
02:53:04 alex_xu Qiming: you mean the prefix?
02:53:08 Qiming The user_data the instance was created with.
02:53:08 Qiming the API doc says this: OS-EXT-SERV-ATTR:user_databodystring
02:53:09 Qiming New in version 2.3
02:53:41 Qiming alex_xu, it is creating some problems when we try to deal with it in openstacksdk
02:54:39 Qiming alex_xu, when we are creating an instance, we pass in user_data, when we receive a response from CREATE or GET, we have to parse it with a prefex
02:55:15 Qiming alex_xu, it is not like the other attributes, kernel_id, root_device_name, ramdisk_id, reservation_id, launch_index, and hostname
02:55:31 alex_xu Qiming: yea, that is really a old style. for now, any new added field without prefix any more
02:55:57 Qiming all the others can be treated as extended server attributes, except for user_data
02:56:02 alex_xu but for back-compatible, we can't remove the prefix directly. at least, it needs a microversion
02:56:03 gmann Qiming: yea as alex_xu mentioned, they were old notation which we have to keep supporting
02:56:46 Qiming so, a microversion to change it (user_data) back is acceptable?
02:56:50 gmann but can you access kernel_id without prefix in server GET ?
02:57:03 Qiming gmann, no
02:57:14 gmann ok
02:57:28 Qiming kernel_id didn't come from user request, users won't expect that
02:57:54 gmann Qiming: ok on create things you mean, got it
02:57:54 alex_xu Qiming: if just change a prefix for a field, i'm not sure it is worth to do that
02:58:08 gmann because GET server has all those with prefix like OS-EXT-SERV-ATTR:kernel_id
02:58:09 Qiming same question for 'personality', which is also an "input only" attribute
02:58:26 Qiming once provided to create/POST, we get no chance to see it again, :)
02:58:30 alex_xu Qiming: personality is a field plan to remove
02:59:51 Qiming gmann, for attributes "added" at server side, it is okay to add a prefix, but for 'user_data', it is weird that its name has changed when I'm retrieving it
03:00:13 gmann alex_xu: yea and that was the reason to plan remove
03:00:58 Qiming ya, removal might be the right thing to do
03:01:36 Qiming anyway, 'personality' is not heavily used like 'user_data' AFAICT
03:02:32 Qiming in the same spirit, maybe 'host_status' for example should have a prefix, :)
03:04:17 gmann Qiming: yea those are not consistent actually due to legacy v2 way was like that and in v2.1 we try to do without prefix as no more extensions
03:04:19 alex_xu Qiming: for any new field, we won't add prefix
03:04:32 alex_xu gmann: yea
03:05:41 Qiming alex_xu, I don't think we should make the prefix decision based on whether it is 'new' or not. Instead, we may want to make the server attributes naming consistent.
03:06:16 alex_xu Qiming: yes, the 'new' one, i mean new in the request also
03:06:57 Qiming ya, that makes sense. I am just trying to raise some awareness about consistency
03:07:20 alex_xu Qiming: yea, agree with you, that should consistent
03:08:04 Qiming would it be on your agenda to remove the prefix from user_data in the response body?
03:08:16 gmann but things is we cannot change old one (which are with prefix) without microversion and still for older version they will be with prefix
03:08:56 gmann alex_xu: we can do for all those in single version bump? what you say, worthy to microversion that?
03:08:58 Qiming yes, I'm 100% with you on the requirement to bump microversion
03:09:06 alex_xu gmann: yea, i think that also
03:09:41 Qiming great, if there is a plan to "fix" it at server side, I will abandon the fix in SDK -- https://review.openstack.org/#/c/443036/
03:10:35 gmann Qiming: still we fix on nova side you need that fix on sdk to support the older version request
03:11:13 alex_xu yes, so you still have same problem on the old version
03:11:25 Qiming gmann, SDK has its own problems to fix, but I hope a full-fleged microversion support will be in place soon
03:11:28 alex_xu try to know what kind of try you got in the openstacksdk
03:12:14 alex_xu Qiming: so SDK still need to support older version of nova api, right? so it still need to care about the user_data field with prefix
03:12:53 gmann yea
03:13:21 gmann sdk fix is anyways needed irrespective of nova fix that in new version or not
03:13:26 Qiming yes, but that will become a different topic. there are still other fields that are "request-only", "response-only", "valid-in-both-direction-but-RENAMED", :_
03:13:42 Qiming gmann, exactly
03:14:51 gmann alex_xu: i think its little bit overhead to microversion that as we have lot of other inconsistency like CamelCase things etc but if we do we should do in one shot but again that can change lot of APIs :)
03:15:29 alex_xu gmann: yes, but we said we won't fix the CamelCase things
03:15:42 gmann yeaaa
03:16:14 gmann +1 on that, it unnecessary and overhead to fix those
03:17:16 alex_xu so...remove the prefix, Qiming will get benefit, and also have people already make their code aware the prefix, will get overhead to fix that.
03:18:10 alex_xu so...the question will be, how much benefit we got from removing prefix, is that enough for other people change their client code to remove fix?
03:19:23 gmann yea thats true, its overhead for existing users and benefit for new
03:21:48 alex_xu Qiming: anyway, my first todo is getting clear what kind of trouble you got in the sdk
03:22:02 Qiming okay
03:32:06 gmann yea +1
03:33:42 openstackgerrit Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162
03:33:42 openstackgerrit Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754
03:33:43 openstackgerrit Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891
03:33:44 openstackgerrit Dan Smith proposed openstack/nova master: Add get_by_instance_uuids() to InstanceMappingList https://review.openstack.org/443292
03:33:44 openstackgerrit Dan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174
03:33:45 openstackgerrit Dan Smith proposed openstack/nova master: Remove Mitaka-era service version check https://review.openstack.org/442861
03:33:45 openstackgerrit Dan Smith proposed openstack/nova master: Make server_groups determine deleted-ness from InstanceMappingList https://review.openstack.org/443293

Earlier   Later