| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 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 ^ | |
| 13:33:45 | bauzas | cdent: you'll see now the conditional branch for checking the filters before calling the placement service | |
| 13:34:47 | bhagyashris | cdent: I have few questions in my mind regarding Scheduler calling the Placement API [1] https://review.openstack.org/#/c/417961. 1. As it updates allocation information at the placement db so is there a need of compute node table for resource tracking? | |
| 13:37:07 | cdent | bhagyashris: the resource tracker and the nova-scheduler will carry on needing to know about compute nodes, yes. Is that what you're asking? The placement services itself will not need to know about the compute node table, just the uuids of those compute nodes, represented as resource providers in the placement api | |
| 13:37:48 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova: libvirt: ephemeral disk support for virtuozzo containers https://review.openstack.org/312488 | |
| 13:42:29 | openstackgerrit | Claudiu Belu proposed openstack/nova: hyper-v: Do not allow instances with pinned CPUs to spawn https://review.openstack.org/424116 | |
| 13:47:18 | sfinucan | lyarwood: Done and done https://review.openstack.org/#/c/418371/1 | |
| 13:47:45 | sfinucan | johnthetubaguy: ^ that looks like a straightforward +W - could you take a glance if you have a moment? | |
| 13:49:13 | lyarwood | sfinucan: cheers | |
| 13:50:22 | bhagyashris | cdent: I know , i am asking lot of questions :) I just want to know if we are using the placement apis then will compute node table be needed in that case? If it will used then in which case it will be used and for what? | |
| 13:51:29 | diga | jaypipes: Hi | |
| 13:51:31 | johnthetubaguy | sfinucan: ack, thanks | |
| 13:51:31 | cdent | bhagyashris: it will carry on being used for keeping track of the compute nodes because nova still needs to know about them | |
| 13:51:51 | cdent | diga: jaypipes is on PTO, maybe somebody else can help? | |
| 13:52:04 | diga | cdent: Hi, sure | |
| 13:52:20 | diga | cdent: https://review.openstack.org/#/c/423872/ can you review this spec - placement notification | |
| 13:53:09 | cdent | yeah, sure, will stick that on my list for today | |
| 13:54:22 | diga | cdent: :) thank you! | |
| 13:54:31 | diga | cdent: we have meeting now right ? | |
| 13:54:36 | cdent | yeah, in five minutes | |
| 13:55:00 | diga | okay | |