| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-23 | |||
| 21:01:27 | dansmith | is that all? | |
| 21:02:57 | mriedem | and https://review.openstack.org/#/c/595864/ | |
| 21:03:03 | melwitt | dansmith: need stable review for this https://review.openstack.org/595864 master change not merged yet, so we'll have to hold till later for the second +2 | |
| 21:03:20 | melwitt | meaning, I'll ask tonyb after the master change lands | |
| 21:03:32 | melwitt | for the +W | |
| 21:03:34 | openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Handling a down cell https://review.openstack.org/595892 | |
| 21:04:57 | dansmith | melwitt: okay I slapped a +2 on there | |
| 21:05:14 | melwitt | thx | |
| 21:06:01 | melwitt | ok, cool. just have to babysit the patches through the gate, get tonyb for the backports, then should be good to go | |
| 21:16:06 | openstackgerrit | Merged openstack/nova master: Normalize dashless 'resource provider create' uuid https://review.openstack.org/567191 | |
| 21:30:44 | openstackgerrit | Merged openstack/nova master: libvirt: Don't react to VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED events https://review.openstack.org/594508 | |
| 21:30:50 | openstackgerrit | Merged openstack/nova master: Update contributor guide for Stein https://review.openstack.org/591258 | |
| 21:30:56 | openstackgerrit | Merged openstack/nova master: [placement] Add functional test to verify presence of policy https://review.openstack.org/595559 | |
| 21:34:07 | mriedem | tonyb: can you hit this for RC3? https://review.openstack.org/#/c/595864/ | |
| 21:37:55 | tonyb | mriedem: done | |
| 21:38:34 | tonyb | anything else you need for RC3 you knwo where I am | |
| 21:40:31 | mriedem | the bottom of the world? | |
| 22:50:29 | openstackgerrit | Merged openstack/nova master: Add functional test for affinity with multiple cells https://review.openstack.org/585073 | |
| #openstack-nova - 2018-08-24 | |||
| 13:21:07 | mnaser | we have plenty of capacity of both, but i have a proposed solution where it just defaults to requiring hardware virt but allowing user to control that value if need be | |
| 13:21:38 | sean-k-mooney | mnaser: right but that is not something you can do via an image today | |
| 13:21:49 | mnaser | sean-k-mooney: it is, using the `img_hv_type` property | |
| 13:21:57 | sean-k-mooney | mnaser: that would be better handeled in a weigher | |
| 13:22:12 | mnaser | if you set it to `kvm`, it'll filter only those that can do hardware acceleration | |
| 13:22:20 | sean-k-mooney | mnaser: no that just allowas you to select the hypervior not the arch | |
| 13:22:27 | mnaser | sean-k-mooney: combined with hw_architecture :) | |
| 13:22:33 | mnaser | and https://review.openstack.org/#/c/566425/ | |
| 13:22:52 | sean-k-mooney | hw_arcitecture is menat to defien the arch of the vm. | |
| 13:23:37 | sean-k-mooney | mnaser: your relying on the fact that today kvm acclerate does not work when you are emulating a different architecture | |
| 13:23:41 | openstackgerrit | Chris Dent proposed openstack/nova master: DNM: Make nova tests pass with externalized placement https://review.openstack.org/596291 | |
| 13:24:07 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Add subtree filter for GET /resource_providers https://review.openstack.org/595236 | |
| 13:24:31 | mnaser | sean-k-mooney: i don't think that's likely going to change anytime soon™ | |
| 13:24:55 | sean-k-mooney | mnaser: well my first respocne to that patch is we should revert it with out a spec | |
| 13:25:12 | mnaser | and that would mean we can't deliver multiarchitecture in our cloud | |
| 13:25:17 | mnaser | so i'm not sure how that benefits anyone | |
| 13:25:33 | mnaser | the patch doesn't hurt anyone except help users deliver a better openstack experience | |
| 13:25:34 | sean-k-mooney | mnaser: you can you just need a weigher. | |
| 13:26:00 | mnaser | doesnt the scheduler filter out N number of items to weight | |
| 13:26:08 | sean-k-mooney | mnaser: my issue is you did this in a filter so its a hard requirement instead of a perference | |
| 13:26:15 | mnaser | it is not | |
| 13:26:32 | mnaser | if the hw_architecture field is empty | |
| 13:26:41 | mnaser | or there is no default configured value | |
| 13:26:43 | mnaser | there is no enforcement | |
| 13:27:03 | sean-k-mooney | yes but i cant set hw_architecture and hv_type anymore | |
| 13:27:09 | mnaser | yes you can | |
| 13:27:19 | mnaser | this patch only uses the configured default IF none is specified in the image. | |
| 13:27:32 | mnaser | you are more than welcome to set hw_arch to aarc64 and hv_type to qemu | |
| 13:27:40 | mnaser | and you'll get software virtualized arm64 vm | |
| 13:27:59 | mnaser | this is just the default values if *none* are specified, which the current openstack nova behavior = put it anywhere. | |
| 13:28:22 | sean-k-mooney | so i can set hw_architecture=x86 and hv_type=kvm and land on a powerkvm node? | |
| 13:28:49 | mnaser | sean-k-mooney: no, if no values are set, you can end up anywhere yes | |
| 13:28:57 | mnaser | but the thing is, 99% of our customers *dont* send hw_arch and hv_type | |
| 13:29:11 | mnaser | because they assume that the cloud is x86_64/kvm which is a reasonable assumption. | |
| 13:29:36 | sean-k-mooney | mnaser: its not how rackspace used to run there public cloud | |
| 13:29:38 | mnaser | multiarchitecture clouds are rare, so asking every single customer/user to tag their images with an architecture is not really smooth user experience, especially in a transition | |
| 13:30:21 | mnaser | sure. so you're saying that for someone to upload an image into openstack, we need to start asking for 3 more parameters | |
| 13:30:23 | sean-k-mooney | they had a large amount of powerpc nodes at one point with xen as the hypervior running with x86 guests | |
| 13:31:15 | mnaser | well, i'd say that's more of an outlier. i don't see how this helps solve things and make them easier for users overall in a multiarch environment | |
| 13:31:34 | mnaser | because the rax env you're describing sounds still like a single arch one for the user facing stuff | |
| 13:32:45 | sean-k-mooney | mnaser: well my point is if you implemented this as a weigher you would land on the same acrh in 99% of cases and fall back to hardware acllerated emulaton if not native nodes were available. | |
| 13:33:06 | mnaser | sean-k-mooney: but don't weighers run on a subset of compute nodes? | |
| 13:33:19 | sean-k-mooney | the chage is merged in anycase but i really dont think this should have been a bug. | |
| 13:33:30 | sean-k-mooney | mnaser: am the run after all the filters | |
| 13:33:49 | sean-k-mooney | so you go through placment then the filters then the weighers | |
| 13:33:57 | mnaser | i was pretty sure that weighers ran on a subset of hosts | |
| 13:33:58 | sean-k-mooney | they just reorder what the filters pass | |
| 13:34:13 | mnaser | hence the values that would let you pick subsets of hosts when scheduling | |
| 13:35:44 | sean-k-mooney | sorry i missed that last point? | |
| 13:36:03 | mnaser | i thought weighers only ran on a subset of filtered hosts | |
| 13:36:10 | sean-k-mooney | yes | |
| 13:37:19 | mdbooth | mriedem: Briefly back to the topic of evacuation tests, am I right in thinking we probably won't be able to write a full job which does failure injection? If not, I don't think I don't think I'm blocked on that. If we *can* I'm happy to write it if you point me at the right repo and an example to crib from. | |
| 13:37:56 | mnaser | sean-k-mooney: was rax doing x86 on ppc via software or hardware emulation? | |
| 13:38:18 | mdbooth | 'example' wouldn't have to be that similar, just enough to orient myself. I haven't touched the top-level CI jobs before. | |
| 13:38:20 | sean-k-mooney | mnaser: i belive xen allows cross arch hardware emulation | |
| 13:40:17 | mdbooth | mriedem: The ability to assert success in the non-failure case might still be interesting, I guess. It would essentially be a regression test. | |
| 13:40:27 | mnaser | sean-k-mooney: i am not too familiar with xen but i would assume that wouldn't be hardware assisted virt (i.e. using VT-x in intel, etc) | |
| 13:40:36 | mnaser | but that's something i dunno much about so i could be entirely wrong | |
| 13:41:33 | sean-k-mooney | mnaser: well xen does use vt-x normally if you are running x86 on x86 | |
| 13:41:40 | sean-k-mooney | as does kvm | |
| 13:42:04 | mnaser | right, so this would be the same as software virtualization which can be really slow, which i'm trying to avoid having anyone end up with | |
| 13:42:22 | mnaser | and all of this is optional, if you set none of those settings, it won't affect you. but if you run a cloud where you want to make sure all VMs are hardware virt'd, then you can do that | |
| 13:47:11 | sean-k-mooney | mnaser: its not so much that this change was done that i object to its that the semantics of the existing api were changed without a spec. | |
| 13:47:49 | mnaser | sean-k-mooney: but if you don't configure this very optional value, there will zero behavior change | |
| 13:48:36 | sean-k-mooney | mnaser: yes and if you had those configure before an you upgrade then your cloud may now be broken if they do not have the same semantics | |
| 13:48:56 | mnaser | sean-k-mooney: you couldn't possible have them configured because they don't even exist before? | |
| 13:49:13 | mnaser | s/possible/possibly | |
| 13:49:25 | sean-k-mooney | the image properties | |
| 13:50:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Remove unnecessary default parameter https://review.openstack.org/564451 | |
| 13:58:48 | mriedem | mdbooth: what type of failure needs to be injected? like delete the disk before starting the evacuatoin? | |
| 13:59:06 | mdbooth | mriedem: Any failure in spawn on the destination | |
| 13:59:08 | mriedem | can't really do that from tempest, but could if run from a script | |
| 13:59:21 | mdbooth | I think I chose plug_vifs in my functional test | |
| 13:59:36 | dansmith | mriedem: so on your gate job, | |
| 14:00:02 | dansmith | mriedem: just force-downing the service isn't going to be enough I think, since it will still be running, potentially mucking with allocations and state correction, etc right? | |
| 14:00:07 | mdbooth | Just need to assert that if we fail in spawn in the dest, we only cleanup what we're supposed to and don't delete shared data. | |
| 14:00:18 | mdbooth | Whether that's shared instance dir or shared block. | |
| 14:00:20 | dansmith | you have to actually kill the n-cpu process and force-down it to avoid the wait | |
| 14:00:54 | dansmith | (well, not mucking with allocations until it's deleted maybe anymore, but screaming at least) | |
| 14:01:06 | dansmith | but I think it's more legit if you stop it | |
| 14:01:25 | mriedem | dansmith: force down is what we do in functional tests | |
| 14:01:30 | mriedem | that's all the API checks for | |