Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-23
10:54:06 bauzas that would +1 the functional tests
10:55:02 bauzas I had a shit ton of problems related to the functional tests, but that's done
11:02:32 cdent bauzas: did you consider using wsgi-intercept (as in the pre-existing functional test) instead of doing a server.run()?
11:02:45 bauzas yup
11:02:59 cdent and that wouldn't work?
11:03:06 bauzas but we agreed with sdague on using the Server directly
11:03:22 bauzas cdent: honestly, that looks a nit
11:03:37 cdent I'm not complaining, I'm just trying to understand the decision process
11:03:40 bauzas cdent: given the short deadline, I don't want to discuss again about it
11:03:49 bauzas yeah, I can understand
11:03:58 bauzas but sometimes you need to find solutions that work easily
11:06:04 hachi hello
11:06:15 bauzas cdent: just one point
11:06:26 bauzas cdent: I'm not sure I like https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/test_report_client.py#L89-L92
11:06:42 bauzas cdent: because we are mocking an internal attribute here
11:06:44 hachi how i can use the policy:
11:06:50 hachi "owner" : "user_id:%(user_id)s"
11:06:59 hachi in nova api 2.1
11:07:09 bauzas cdent: in case keystone changes its interface, we wouldn't have mock complaning at all
11:07:15 hachi with newton release
11:07:18 bauzas cdent: but then we would have huge problems
11:07:53 bauzas cdent: I rather preferred to use the keystone public way of avoiding the SC
11:08:17 cdent keystoneauth1 has made a commitment to not change the interface on its public methods without changing the entire name of the package?
11:08:21 bauzas but like I said previously, that looks a nit to me and we could discuss on that later on
11:08:38 bauzas cdent: sure, we can trust them
11:08:47 bauzas cdent: that's just riskier, that's it
11:08:52 bauzas anyway
11:09:17 cdent and even if it did break, we could just fix it when it broke: the tests will have done their job in that case
11:09:19 bauzas I'm totally up discussing on that after FF :)
11:09:52 bauzas probably we could accept not to fake our scheduler client methods and rather mock the Service object
11:10:22 bauzas but I think we could still use the Server proxy to really run an wsgi server and not intercept
11:10:47 bauzas but that's my thoughts - just coming along while tests are running on my local desktop and that I have a bit of time :)
11:11:46 cdent Out of curiosity why do you prefer the server proxy?
11:14:58 bauzas cdent: because that's running our internals
11:15:13 cdent What are "our internals"?
11:15:21 bauzas internal piece of code
11:15:59 bauzas and we're not emulating a socket, we *run* it
11:16:08 bauzas which makes possible to debug the app outside of the test
11:16:26 bauzas but meh.
11:16:58 bauzas anyway, back to work
11:17:00 cdent okay, but when the placement api runs for real, it doesn't use any of the nova Server() handling
11:23:11 openstackgerrit Bob Ball proposed openstack/nova: Use physical utilisation for cached images https://review.openstack.org/353862
11:25:00 openstackgerrit Claudiu Belu proposed openstack/nova: hyper-v: Adds support for VMs with nested virtualization https://review.openstack.org/398509
11:26:42 cdent bauzas: I've got a couple questions on the CoreFilter issue that are probably easier to track here than email. You got time to answer them now or should I just post a response to the email?
11:27:25 bauzas cdent: just throw me a bit of them
11:29:02 cdent In the world before Placement API existed, if I disabled the CoreFilter, that means that select_destinations could return some compute nodes that would reject a "placement" and cause a retry because it didn't have enough cores. Is that right?
11:31:28 openstackgerrit Alex Xu proposed openstack/nova: Limit the min length of string for integer JSON-Schema https://review.openstack.org/415103
11:31:47 cdent bauzus: If it is right, then asking the placement api for vcpu resources is simply short circuiting that retry and we should do that?
11:31:57 johnthetubaguy alex_xu: I would expect no policy.json file in a new install, empty I guess is OK too.
11:32:12 alex_xu johnthetubaguy: got it, thanks
11:32:13 johnthetubaguy alex_xu: in the future I was thinking a fully commented out yaml file, a bit like what we do for config
11:32:27 alex_xu johnthetubaguy: ok
11:33:26 alex_xu johnthetubaguy: I probably figure out a way to implement the 3 cases you pointed out. so I will work with Kevin_Zheng to update the patch.
11:35:00 johnthetubaguy alex_xu: Kevin_Zheng: let me know how that goes, for me the warning message is an optional extra, as we could leave the old rules ill we can get that into olso.policy
11:40:36 bauzas cdent: sorry, missed your question
11:40:54 bauzas cdent: in a world where an operator disables the CoreFilter, we don't verify VCPUs
11:41:14 bauzas cdent: most of them for example are disabiling the DiskFilter for the exact reason it doesn't count correctly
11:41:34 cdent we don't verify vcpus at the scheduler level but do at the compute node level, or we don't very vcpus _anywhere_?
11:41:51 bauzas cdent: if you don't run the CoreFilter, we don't return a limit
11:42:12 alex_xu hachi: we didn't suggest to use user_id based policy check. That was added back to the code just for backward-compatible, it may be removed in the future
11:42:16 bauzas cdent: if so, that's coming to the compute, and then we verify the claim without verifying the limit
11:42:44 bauzas cdent: which means no allocation ratio
11:42:45 cdent interesting
11:43:18 bauzas cdent: so, I'm a bit afraid that a lot of operators have disabled the DiskFilter
11:43:58 bauzas cdent: if now we check the disk size directly without having the aggregates created automatically for the RPs, then they could have problmes
11:44:05 cdent so your idea is to remove resource classes from the request to /resource_providers based on which filters are disabled
11:44:11 bauzas cdent: yup
11:44:23 bauzas cdent: lemme upload the change this afternoon and you'll see
11:44:26 cdent and the change would solely be on the nova-scheduler side
11:44:33 bauzas yup
11:45:03 cdent cool. It makes sense. My main concern was that we should change something on the placement server-side based on nova's config
11:45:08 bauzas I just have a problem with our FakeDriver creating the same hypervisor hostname for all our computes
11:45:28 bauzas so, once I fix that, I'll upload
11:46:26 openstackgerrit Chris Dent proposed openstack/nova: Optional separate database for placement API https://review.openstack.org/362766
11:49:07 openstackgerrit Stephen Finucane proposed openstack/nova: Fix and add some notes to the cells v2 first time setup doc https://review.openstack.org/421421
11:55:49 openstackgerrit Alvaro Lopez Garcia proposed openstack/nova: Ensure that periodic reclaim cleans DB deleted instances https://review.openstack.org/323250
12:00:27 openstackgerrit Zhenyu Zheng proposed openstack/nova: Fix device taging after API microversion 2.37 https://review.openstack.org/423952
12:28:16 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(5): Introduce base PowerVM driver (ovs vif) https://review.openstack.org/422512
12:39:16 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(5): Introduce base PowerVM driver (ovs vif) https://review.openstack.org/422512
12:48:38 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance-live_migration_abort notification https://review.openstack.org/420453
12:55:46 lyarwood sfinucan: thanks for the review on the findmnt change, https://review.openstack.org/#/c/418371/ is another straight forward one adding a missing releasenote if you have time today
13:02:49 snikitin johnthetubaguy: Hi John! can you look at instance diagnostics implementation for Xen please? https://review.openstack.org/#/c/399613/
13:06:48 hachi alex_xu thank you.
13:06:59 hachi but i don't want my users within the same project do accidently delete the VM(s) of each other.
13:07:18 hachi how i can do that without user_id policy ?
13:09:12 bhagyashris cdent: Hi,
13:11:21 alex_xu hachi: you can lock the instance
13:14:21 cdent bhagyashris: hi, what's up?
13:14:55 dims sean-k-mooney : jaypipes : https://review.openstack.org/#/c/423718/ does the trick for getting os-vif's linuxbridge working
13:15:33 hachi alex_xu thank you for the tip. I will try that.
13:15:43 amrith andreykurilin, ping. I'm having a little issue with nova's 7.0.0 client, would you have a couple of minutes to help out? thx
13:16:59 amrith one part of this is a change you submitted, https://review.openstack.org/#/c/412497/
13:17:31 amrith appears that something changed in 7.0.0 which I'm not quite grok'ing. pl ping me if you have a minute andreykurilin. thx
13:18:03 openstackgerrit Zhenyu Zheng proposed openstack/nova: Add new policy for server list/detail with all_tenants https://review.openstack.org/415330
13:19:56 openstackgerrit Julian proposed openstack/nova: Create cmd/script that prints JSON Schema of Notification Payload Classes https://review.openstack.org/411836
13:21:27 alex_xu hachi: np
13:27:21 openstackgerrit Zhenyu Zheng proposed openstack/nova: Add sort_key white list for server list/detail https://review.openstack.org/415142
13:31:32 openstackgerrit Sylvain Bauza proposed openstack/nova: Fix the FakeDriver using same hypervisor names https://review.openstack.org/424110
13:31:32 openstackgerrit Sylvain Bauza proposed openstack/nova: WIP: Scheduler calling the Placement API https://review.openstack.org/417961
13:32:06 bauzas cdent: johnthetubaguy: dansmith: latest versions for the high-prio scheduler placement changes ^

Earlier   Later