Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-25
14:26:04 mriedem so i'm not sure what is triggering it
14:26:22 cdent yes, the failure will be random in the eventlet case, that's why I'm wondering if that's the cause
14:26:41 cdent if you force a yield and it works consistently, then that might be it
14:26:47 cdent and we can consider "proper" solutions
14:26:54 cdent if it makes no difference, then ...
14:28:40 cdent mriedem: oh I see your saying not that a test fails randomly but rather different tests randomly fail
14:28:54 mriedem alex_xu: you're missing the GET versions samples https://review.openstack.org/#/c/457181/
14:29:15 mriedem cdent: yeah
14:29:17 cdent in that case, is there some way to centralize the sleep(0)
14:29:38 cdent like in some central method that is making the request?
14:29:39 openstackgerrit Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322
14:30:10 mriedem cdent: probably here File "nova/tests/functional/api/client.py", line 164, in api_request
14:30:15 mriedem also https://bugs.launchpad.net/nova/+bug/1686109
14:30:15 openstack Launchpad bug 1686109 in OpenStack Compute (nova) "requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",)) in functional tests" [Medium,Confirmed]
14:30:19 mriedem is the bug i reported for tracking it
14:31:59 erhudy when an instance is launched and neutron ports are attached, does nova do that without calling the interface attach action from the API? not having os_compute_api:os-attach-interfaces disallows it after instance creation as expected, but at launch time it seems to take a different path
14:32:04 erhudy albeit this is on liberty so things may be different now
14:32:07 cdent mriedem i can poke at it after I'm done poking at devstack/uwsgi/nova/metadata, unless you're on the case?
14:33:25 mriedem cdent: i'm not no
14:33:41 cdent ✔
14:33:44 mriedem erhudy: same internal code, different API entrypoint
14:34:01 mriedem erhudy: so no, server create does not call os-attach-interfaces
14:34:20 alex_xu mriedem: ah, thanks, rebase merge that with os-hosts change...
14:34:36 mriedem erhudy: i believe there is a separate policy rule for disabling networking on server create
14:34:43 mriedem alex_xu: ah
14:35:29 erhudy mriedem: thanks for the explanation
14:35:57 mriedem erhudy: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L533
14:36:06 mriedem is the policy to disable creating networks on a server create request
14:36:15 mriedem well,
14:36:21 mriedem requesting specific networks i should say
14:36:38 mriedem if you omit networks, but one is available to the project, a port will still be created on that network
14:37:08 mriedem there is probably a bug there wrt the 2.37 microversion and requesting networks='none'
14:37:11 mriedem since we don't check for that case
14:37:24 openstackgerrit Alex Xu proposed openstack/nova master: Deprecate Multinic, floatingip action and os-virtual-interface API https://review.openstack.org/457181
14:38:29 erhudy alright, thanks for pointing me to the right place
14:46:02 dane-fichter mriedem: barbican can handle either 'aes' or 'AES', you can see it in the functional tests
14:46:58 mriedem erhudy: fyi https://bugs.launchpad.net/nova/+bug/1686113
14:46:58 openstack Launchpad bug 1686113 in OpenStack Compute (nova) "os_compute_api:servers:create:attach_network does not account for networks='none' and microversion 2.37" [Low,Triaged]
14:47:05 mriedem dane-fichter: ok
14:47:16 mriedem just reply to my question in the review i suppose
14:47:23 dane-fichter mriedem: will do
14:49:28 openstackgerrit John Garbutt proposed openstack/nova master: Add description to policies in migrations.py https://review.openstack.org/459727
14:50:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add BDM to InstancePayload https://review.openstack.org/448779
14:56:34 openstackgerrit Chris Dent proposed openstack/nova master: DNM: Use greenthread sleep to unlock api test threads https://review.openstack.org/459733
14:57:11 cdent mriedem: one way around that ^ problem would be use to use wsgi-intercept instead of spawning a separate thread
14:57:19 mriedem dane-fichter: also note that the test that's dependent on this nova fix is still failing http://logs.openstack.org/59/455459/17/check/gate-barbican-simple-crypto-dsvm-tempest-ubuntu-xenial-nv/eb0372f/console.html#_2017-04-24_21_31_53_893425
14:57:26 mriedem dane-fichter: so it'd be nice to see that passing
14:58:07 openstackgerrit John Garbutt proposed openstack/nova master: Fix rendering of several policy rule descriptions https://review.openstack.org/459734
14:58:10 dane-fichter mriedem: yeah that's failing for other reasons, but agreed.
14:59:57 openstackgerrit Sean Dague proposed openstack/nova master: disable keepalive for functional tests https://review.openstack.org/459735
15:03:21 sfinucan johnthetubaguy: RE: https://review.openstack.org/459734
15:03:28 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992
15:03:52 sfinucan johnthetubaguy: what's actually doing the rendering? Couldn't we change that instead to strip newlines or whatnot
15:03:55 openstackgerrit sahid proposed openstack/nova master: libvirt: update LibvirtConfigGuestDeviceAddress to provide XML https://review.openstack.org/459737
15:03:56 openstackgerrit sahid proposed openstack/nova master: libvirt: set full description of the controller used by disk https://review.openstack.org/459738
15:03:56 openstackgerrit sahid proposed openstack/nova master: libvirt: rearange how scsi controller is defined https://review.openstack.org/459739
15:03:57 openstackgerrit sahid proposed openstack/nova master: libvirt: update logic to configure device for scsi controller https://review.openstack.org/459740
15:03:57 openstackgerrit sahid proposed openstack/nova master: libvirt: update the logic to configure volume with scsi controller https://review.openstack.org/459741
15:04:13 mriedem sdague: cool i forgot that was something we had for eventlet
15:04:20 mriedem sdague: that will likely fix it
15:08:03 mriedem test_popped_collar?
15:10:16 moshele jaypipes: hi can you review some pci stuff https://review.openstack.org/#/c/453938/
15:10:17 openstackgerrit Matthew Treinish proposed openstack/nova master: Remove nova-cert https://review.openstack.org/459460
15:12:47 jaypipes moshele: yes sir!
15:13:29 moshele jaypipes: thanks :)
15:14:21 bauzas johnthetubaguy: something is confusing me, and I'd love your insights : would having the claims in the scheduler solve the RAX problem requiring to use CachingScheduler?
15:14:49 bauzas johnthetubaguy: in other words, could we deprecate CachingScheduler if we merge scheduler claims in Pike ?
15:15:59 mriedem bauzas: placement solves the performance issue, or is supposed to solve the performance issue, which is why the caching scheduler exists,
15:16:04 mriedem but caching scheduler doesn't use placement
15:16:41 openstackgerrit Daniel Pawlik proposed openstack/nova master: Added kvm_hidden feature https://review.openstack.org/459753
15:17:50 bauzas mriedem: okay, because we don't fully fetch the large list of hosts, got it
15:18:09 bauzas (in the filter scheduler)
15:18:24 sean-k-mooney the caching scheduler solve a part of scheduler performance but with the placement api and schduler claim you would nolonger have race condtions in the scheduler and could scaler it liniearly horizontally by adding more schdedulers
15:18:26 mriedem well and filters in db
15:18:41 mriedem bauzas: johnthetubaguy + osic said filter scheduler + placement was still slower than caching scheduler because of the retries
15:18:46 mriedem due to not claiming in the scheduler
15:19:16 mriedem so if we pick the correct host the first time in the scheduler by doing the correct claim, we should mitigate the need for retries
15:19:27 mriedem which is also why i nag about not relying on retries in the claims in scheduler spec
15:19:28 bauzas okay
15:19:31 mriedem or assuming it will work, or be there
15:19:34 mriedem it == retries
15:20:05 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Claims in the scheduler https://review.openstack.org/437424
15:20:28 bauzas mriedem: dansmith: updated the spec before I forgot to remove an unnecessary work item ^
15:20:32 bauzas jaypipes: too ^
15:21:33 sean-k-mooney mriedem: +1 the claims process needs to be independent of (not depend on ) retries.
15:21:53 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_detach notification https://review.openstack.org/408676
15:22:26 mriedem sean-k-mooney: until we pick the wrong host b/c we didn't know about all of your crazy extra specs and aggregate requirements for NFV :)
15:23:19 openstackgerrit sahid proposed openstack/nova master: numa: fix an uninitialized local variable https://review.openstack.org/458848
15:23:37 sean-k-mooney mriedem: ofcourse life would be so much less interesting without the nfv curve ball but nested resource provides and traits should fix that
15:24:44 bauzas sean-k-mooney: mriedem: anyway, given we only check mem/cpu/disk and not other resource classes in the placement engine, we still need to accept reschedules...
15:24:56 bauzas until we at least have nested RPs
15:25:00 bauzas for NUMA resources
15:25:49 sean-k-mooney bauzas: im reading the spec now but at what point is the claim made? before or after the filters run?
15:25:59 mriedem sean-k-mooney: after
15:26:04 dansmith sean-k-mooney: has to be after, else we don't know what to claim :)
15:26:27 sean-k-mooney ya so it should be after in the weigher stage right
15:26:31 dansmith mriedem: are we holding off on approving this until after forum, or should we just go ahead and merge and handle any feedback as an amendment?
15:26:45 dansmith sean-k-mooney: it's after weighers too
15:27:12 bauzas sean-k-mooney: tbc, it will probably be in the consume_from_request() method or somewhere close to it
15:27:14 dansmith sean-k-mooney: it's at the point at which we pick a host, but before we ask that host to build (whereas currently it's after the host has started to build)

Earlier   Later