Earlier  
Posted Nick Remark
#openstack-nova - 2018-08-08
06:13:11 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Use uuidutils of oslo.utils https://review.openstack.org/589717
06:13:14 openstack Launchpad bug 1644457 in OpenStack Compute (nova) "keypair quota error" [Medium,Confirmed] - Assigned to Vishakha Agarwal (vishakha.agarwal)
06:13:14 gmann #link https://bugs.launchpad.net/nova/+bug/1644457
06:14:06 gmann alex_xu: i agree with doc only update as of now on keypair things, and later if we need we should go with barbican integration as matt mentioned via sdague mail
06:14:13 gmann i just updated the comment there.
06:14:50 alex_xu gmann: yea, that the thing we can do now
06:15:06 gmann alex_xu: +1
06:15:09 gmann vishakha: ^^
06:15:50 gmann next bug i want to discuss is new one show up -
06:15:53 openstack Launchpad bug 1783338 in OpenStack Compute (nova) "Unexpected exception in API method: ValueError: year is out of range" [Medium,Confirmed] - Assigned to Ghanshyam Mann (ghanshyammann)
06:15:53 gmann #link https://bugs.launchpad.net/nova/+bug/1783338
06:15:55 vishakha gmann yes I will update the doc
06:16:06 gmann i commented and confirmed that.
06:16:09 gmann vishakha: thanks
06:16:32 vishakha gmann: thanks for the help
06:16:34 gmann vishakha: you can just make clear in api-ref that in-use field will always be zero for keypairs.
06:16:59 vishakha gmann: ok sure
06:17:01 gmann and some more clarification like keypair is per user only not per projects
06:17:45 gmann alex_xu: on second bug, error is that start or end dates in GET /simple-tenant-usage API is not iso8601 format.
06:18:11 gmann it says year is out of range which i do not know why as attached screenshot in bug show year as '2018'
06:18:28 vishakha gmann : ok
06:18:39 gmann one thing we are surly missing is to handle the value error which leads to 500 in this API
06:21:10 alex_xu gmann: yea, we can update the query schema
06:21:48 gmann as of now we just check string there
06:21:50 gmann #link https://github.com/openstack/nova/blob/e8a73c400846b5be0f12a2eea32bd2c5c5aeb370/nova/api/openstack/compute/schemas/simple_tenant_usage.py#L22
06:22:24 alex_xu yea
06:22:31 gmann need to check if iso8601 format there in json schema or we can do via custom format_checker also
06:22:46 alex_xu I remember we have somewhere use it
06:23:00 alex_xu change-since in server list API i guess
06:24:29 alex_xu gmann: https://github.com/openstack/nova/blob/e8a73c400846b5be0f12a2eea32bd2c5c5aeb370/nova/api/openstack/compute/schemas/servers.py#L592
06:24:30 gmann ah yeah
06:24:32 gmann #link https://github.com/openstack/nova/blob/e8a73c400846b5be0f12a2eea32bd2c5c5aeb370/nova/api/validation/validators.py#L47
06:24:49 gmann alex_xu: thanks, that will be quick
06:24:56 alex_xu but the 2018 is out of range is very strange
06:24:57 gmann i will update the patch for that
06:25:02 alex_xu good to check that
06:25:34 gmann yeah, not sure nova get 2018 or something else. ll get horizon and try out this one and will update on bug
06:25:39 alex_xu but it only say 'year out of range', maybe the code doesn't see the 2018, it will be another value
06:25:43 alex_xu yea
06:26:31 gmann let's move to next bug
06:26:43 gmann there is one high priority bug for href things
06:26:46 openstack Launchpad bug 1705663 in OpenStack Compute (nova) "Wrong href link returned when providing non-existed version in GET version API" [High,In progress] - Assigned to Zhenyu Zheng (zhengzhenyu)
06:26:46 gmann #link https://bugs.launchpad.net/nova/+bug/1705663
06:27:02 gmann i have not got chance to review Kevin_Zheng patch yet, alex_xu did you?
06:27:07 gmann i think he update the PS
06:27:41 alex_xu gmann: no, I forget that one, probably try it today
06:27:45 Kevin_Zheng o/
06:27:58 gmann alex_xu: thanks, i will also check but tomorrow only.
06:29:18 gmann that's all from me on bug things, anything from your side ?
06:29:59 alex_xu gmann: nothing from me
06:30:04 gmann #topic Open Discussion
06:30:30 gmann there is nothing on agend under open. if nothing we can close office houre early
06:35:16 gmann alex_xu: anything else ?
06:37:14 alex_xu nothing from me
06:37:26 gmann let's close then. thanks
06:37:32 gmann #endmeeting
06:37:34 openstack Meeting ended Wed Aug 8 06:37:32 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
06:37:35 openstack Minutes: http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-08-08-06.02.html
06:37:36 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-08-08-06.02.txt
06:37:37 openstack Log: http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-08-08-06.02.log.html
07:05:02 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: api-ref: fix min_version for parent_provider_uuid in responses https://review.openstack.org/579577
07:05:03 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: [placement] api-ref: add description for 1.29 https://review.openstack.org/589407
07:30:08 gibi good morning nova
08:10:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use placement 1.28 in scheduler report client https://review.openstack.org/583667
08:14:30 openstack Launchpad bug 1783635 in OpenStack Compute (nova) pike "Live migration failed.: AttributeError: 'Guest' object has no attribute 'migrate_configure_max_speed'" [High,Fix committed] - Assigned to Lee Yarwood (lyarwood)
08:14:30 ivve hey guys.. the new migrate_configure_max_speed in guest.py (fix in pike https://bugs.launchpad.net/nova/+bug/1783635) but from queens.. bandwidth=0 but is capped @ 1024KB/sec
08:15:02 ivve i've applied it manually for pike. 0 should be unlimited?
08:15:59 ivve domain_xml=None, bandwidth=0):
08:15:59 ivve def migrate(self, destination, migrate_uri=None, params=None, flags=0,
08:16:20 ivve seems to set itself to 1
08:16:39 ivve im no good at debugging this so asking for help :)
08:18:41 ivve note: cap is for entire host, not per vm
08:18:46 ivve instance..
08:21:13 lyarwood sahid: ^ I think bandwidth=0 is unlimited right?
08:21:23 lyarwood https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateSetMaxSpeed doesn't help
08:22:04 ivve it should be, but my migrations are 1024KB/sec capped
08:22:32 ivve just evacuated a host and watched my bridge.. 1024KB
08:22:41 ivve so it seems to set itself to 1
08:22:48 ivve 1MB/sec
08:24:33 lyarwood ivve: live_migration_bandwidth isn't set in nova.conf?
08:24:43 ivve is it meant to be set via nova configuration and/or metadata for hosts/instances?
08:24:51 ivve lyarwood: let me check!
08:25:43 ivve kinda stumbled upon this when i updated a pike
08:25:47 lyarwood ivve: https://github.com/openstack/nova/blob/stable/pike/nova/virt/libvirt/driver.py#L6939-L6942 - you should see it logged here as well btw
08:26:45 openstack bug 1783635 in OpenStack Compute (nova) pike "Live migration failed.: AttributeError: 'Guest' object has no attribute 'migrate_configure_max_speed'" [High,Fix committed] https://launchpad.net/bugs/1783635 - Assigned to Lee Yarwood (lyarwood)
08:26:45 ivve so im guessing more issues will follow, not only the fix in bug 1783635
08:27:12 ivve well actually im wrong
08:27:18 sahid lyarwood: yes but that can be overidden by the api call migrateToUri
08:27:20 ivve thats for openstack-ansible to fix
08:27:23 ivve i guess
08:28:08 lyarwood ivve: that's the only other fix on top of 16.1.4 to do with migration AFAIK
08:28:34 ivve lyarwood: you are right, the option is not even in nova.conf
08:29:23 ivve setting it now and restarting, sec for confirmation
08:30:05 lyarwood ivve: it should default to 0
08:30:17 lyarwood ivve: I was trying to ensure it wasn't set to 1
08:31:14 ivve it wasn't in the libvirt stanza at all
08:31:14 lyarwood sahid: it defaults to 0 there as well so I have no idea where 1 is coming from for ivve
08:31:21 ivve so im guessing defaults to 1 ? :D
08:31:41 sahid 1 is comming is you are using linux bridge
08:31:46 sahid to slow the migration

Earlier   Later