| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-19 | |||
| 16:21:14 | mriedem | i'm kind of waiting for ^ to settle before digging into it | |
| 16:39:34 | jaypipes | mriedem: the nova-cyborg thing? | |
| 16:40:35 | mriedem | ye | |
| 16:40:37 | mriedem | *yes | |
| 16:51:40 | sean-k-mooney | cdent: there were some mixed messages from me vs dan and jay. i wanted them to either document everything or drop the api stuff. dan wanted the api stuff remvoed and i think jay agreed | |
| 16:52:18 | sean-k-mooney | cdent: i was fine with removing the cyborg api stuff which sundar may not have picked up on but i dislike have only some of the enpoints int he spec | |
| 16:53:25 | sean-k-mooney | i think dansmith jaypipes and i all agree we would like to see the integration follow the os-vif and os-bricks model where os-acc become the nova integration point | |
| 16:53:26 | cdent | sean-k-mooney: I said to him that it would be easier to evaluate the API if it were all in one place | |
| 16:53:43 | cdent | And if the API isn't needed at this stage, then cool | |
| 16:54:00 | cdent | I was simply trying to help him navigate what has proven to be a strenuous process | |
| 16:54:02 | sean-k-mooney | cdent: that is true but the one place could be a cyborg spec that we provide input into yes? | |
| 16:55:39 | cdent | yes, if the one place were to happen, then in cyborg would be the place | |
| 16:58:00 | efried | problem there being that they've had very little input on the cyborg specs from outside the cyborg team. | |
| 16:58:40 | efried | I think it may have been on my recommendation (which was for that reason ^) that Sundar put this one into nova-specs. | |
| 16:59:03 | dansmith | there really shouldn't need to be a lot of input from us on cyborg APIs I don't think | |
| 16:59:18 | dansmith | if we keep the discussion on the nova side to the workflow and interaction with the library, | |
| 16:59:20 | sean-k-mooney | efried: well you and i have both left quite a lot of feedback at different times but i dont think alot of it has been incorperated. some definetly has but we have had the same converstaton several times | |
| 16:59:31 | dansmith | the server-side stuff should be discernible from that I think | |
| 16:59:49 | dansmith | sean-k-mooney: yeah, definitely feel like we've gone in circles a lot on this, approaching exhaustion | |
| 17:01:01 | openstackgerrit | Elod Illes proposed openstack/nova master: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 17:10:11 | jaypipes | jangutter: I really like the "before and after" sections in https://review.openstack.org/#/c/607610/3/specs/stein/approved/generic-os-vif-offloads.rst (e.g. lines 133-177). makes it much easier to see how the changes affect things. ++ | |
| 17:25:13 | sean-k-mooney | jaypipes: dansmith i responded on the cyborg spec to say please remove the cyborg api section. | |
| 17:25:45 | sean-k-mooney | jaypipes: dansmith also do we all agree the indirect usecase where the acclerator is not attach to the vm should not be in the spec? | |
| 17:26:35 | jaypipes | sean-k-mooney: I just finished up with jangutter's spec on os-vif object model changes. adding some comments to the cyborg spec now... | |
| 17:26:47 | sean-k-mooney | my understanding is that the instance will not be the consumer of the devices in placement and since they are not attach to the nova instance nova should not care | |
| 17:27:05 | cdent | efried: we (you?) need to come up with a plan for replacing the tests that use rp_object as added in https://review.openstack.org/#/c/560444/ | |
| 17:27:16 | sean-k-mooney | jaypipes: oh ya i need to go back to that one | |
| 17:28:23 | sean-k-mooney | jaypipes: am one point i made on the code which is not in the spec is we should not use the term datapath offlod since the representor netdev is actull part of the control plane. | |
| 17:30:47 | jaypipes | sean-k-mooney: I said on the spec that I think "OffloadBase" is fine and removing "Datapath" would be good. | |
| 17:31:55 | sean-k-mooney | i realise when i clicked the link i have only looked at the code for this so im currently readign the spec for the first tiem | |
| 17:35:01 | sean-k-mooney | jaypipes: if you have not seen it can you reivew this comment on the code to see if you agree https://review.openstack.org/#/c/572081/9/os_vif/objects/vif.py@376 i will see how that relates to the spec | |
| 17:41:20 | efried | cdent: That should be easy peasy. Did you want me to do that in nova, placement, or both? | |
| 17:41:34 | cdent | efried: it only exists in nova | |
| 17:41:40 | efried | stand by. | |
| 17:44:29 | openstackgerrit | Merged openstack/nova stable/rocky: Handle unicode characters in migration params https://review.openstack.org/618734 | |
| 17:51:34 | openstackgerrit | Eric Fried proposed openstack/nova master: Nix refs to ResourceProvider obj from libvirt UT https://review.openstack.org/618786 | |
| 17:51:35 | efried | cdent: There ya go ^ | |
| 17:51:41 | cdent | rad | |
| 17:52:16 | cdent | thanks | |
| 17:52:21 | efried | There's more refactoring that could be done there, but this is roughly the easiest. | |
| 17:52:25 | efried | without being too hacky | |
| 17:54:02 | efried | cdent: BTW, pretty sure the origin of the test code was bhagyashris. This doesn't look like my style at all. | |
| 17:54:34 | cdent | efried: noted. I just went by git blame when raising the "alarm`' | |
| 17:54:47 | efried | yup, and she's not around atm anyway. Easy enough fix. | |
| 18:01:04 | efried | jaypipes, mriedem, bauzas: ----^ easy one | |
| 18:07:35 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 18:07:36 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Delete the placement code https://review.openstack.org/618215 | |
| 18:08:51 | cdent | feh, that's not going to work after a merge | |
| 18:48:54 | larsks | Hey folks. Should disk-related instance resource quotas (such as quota:disk_write_bytes_sec) be applied when booting from a volume? | |
| 19:21:53 | cfriesen | larsks: I think it's supposed to be applied, at least for libvirt/qemu. | |
| 19:26:59 | sean-k-mooney | cfriesen: yes it is but i just tested with devstack and it does not work on master | |
| 19:27:43 | sean-k-mooney | cfriesen: larsks moved to public pastbin http://paste.openstack.org/show/735692/ | |
| 19:28:33 | sean-k-mooney | im link 95% sure this used to work | |
| 19:28:36 | cfriesen | sean-k-mooney: I think it's "quota:write_bytes_sec" | |
| 19:29:05 | cfriesen | no, that webpage was wrong | |
| 19:29:12 | sean-k-mooney | quota:disk_write_bytes_sec is what horizon set | |
| 19:30:16 | sean-k-mooney | ill set all the limits and see what hapes perhaps its just that one. i think this works with the ceph backend but maybe for boot form volume you have to use cinder qos | |
| 19:34:20 | sean-k-mooney | cfriesen: larsks nope still ignored http://paste.openstack.org/show/735693/ | |
| 19:40:09 | openstackgerrit | Jack Ding proposed openstack/nova master: Add HPET timer support for x86 guests https://review.openstack.org/605902 | |
| 19:46:08 | larsks | cfriesen: thanks, and sean-k-mooney thanks for checking. What I'm curious about is whether or not that is expected behavior... | |
| 19:46:17 | larsks | I.e., should I open a bug for this? | |
| 19:46:25 | sean-k-mooney | larsks: it is expect to work and yes | |
| 19:46:38 | larsks | Ack, I'll do that right now, then. | |
| 19:47:02 | sean-k-mooney | but we also advise peole not to use falvor qouta any more even though we have not deprecated them offically | |
| 19:47:24 | larsks | Oh, that's news. Why is that? | |
| 19:47:49 | sean-k-mooney | because cinder and neutron both have there own qos apis which are richer and better tested | |
| 19:48:38 | larsks | Okay. Being able to associate a collection disk/network/etc quotas with a flavor is very convenient. | |
| 19:49:04 | larsks | But I can see that having these resource quotas managed in different places could lead to confusion and duplication of effort. | |
| 19:49:09 | sean-k-mooney | it is but its legacy functionality that was supperseed by qos apis in the services | |
| 19:49:36 | sean-k-mooney | that daid if you are not using cinder or neutron an want that fuctionality the falvor were the only way to do it | |
| 19:49:45 | larsks | Fair enough. Do you know if there is documentation that would suggest avoiding flavor quotas? I may need to convince someone to do so. | |
| 19:50:26 | sean-k-mooney | larsks: not that im aware of but most people dont know they exist and we just dont activly publicise that fact to new users | |
| 19:50:36 | larsks | Got it. Okay, thanks! | |
| 19:56:32 | cdent | Is anyone else seeing HackingTestCase.test_check_doubled_words fail on py36 on ubuntu 18.04? It's not failing on macos | |
| 19:58:11 | efried | cdent: I just ran it locally on trusty and it ran okay. | |
| 19:59:00 | efried | I noticed it breaking here: https://review.openstack.org/#/c/618786/ <== is that where you were seeing it, or somewhere else? | |
| 19:59:43 | cdent | first on my placement removal patches, and then on master | |
| 20:12:04 | cdent | weird, it's a problem in 3.6 but not 3.7 | |
| 20:18:53 | cdent | oh rich, it passes in stestr in 3.7, but not with testtools.run or unittest | |
| 20:33:05 | larsks | sean-k-mooney: Looks like there is already a bug, from 2016 :). https://bugs.launchpad.net/nova/+bug/1445637 | |
| 20:33:05 | openstack | Launchpad bug 1445637 in OpenStack Compute (nova) "Instance resource quota not observed for non-ephemeral storage" [Wishlist,Opinion] | |
| 20:35:31 | sean-k-mooney | larsks: ah ok let me repriorise it for you | |
| 20:36:14 | larsks | I don't know, maybe at this point it's just a doc bug and the docs should say "use cinder and neutron resource controls". | |
| 20:37:53 | sean-k-mooney | i have set it to confirmed and low. we can propse a docs update as a resolution to the but if we like | |
| 21:01:34 | larsks | sean-k-mooney: ...but flavor quotas *are* still the correct mechanism for controlling cpu and memory limits? | |
| 21:03:40 | sean-k-mooney | larsks: cpu and memory limits? | |
| 21:03:53 | cdent | efried: it's because of this https://bugs.python.org/issue33899 which gets python 3.6.7 and newer versions of python 3.7. I'll make a bug and a patch | |
| 21:04:18 | larsks | sean-k-mooney: right, like quota:cpu_quota. | |
| 21:04:22 | larsks | sean-k-mooney: so really just cpu. | |
| 21:04:35 | sean-k-mooney | larsks: that is also something that in general is not used | |
| 21:05:13 | larsks | Okay. Is there an alternative for that, or is that just something that was considered less useful? | |
| 21:05:18 | sean-k-mooney | larsks: most of those values are from lxc | |
| 21:05:24 | sean-k-mooney | or vm ware | |
| 21:06:08 | sean-k-mooney | many of them never work with libvirt/kvm cpu_shares did but not the rest | |
| 21:06:35 | sean-k-mooney | the same is true fo the memory limits | |
| 21:06:40 | sean-k-mooney | https://docs.openstack.org/nova/latest/user/flavors.html | |
| 21:07:15 | sean-k-mooney | all of the flavor quota atibute came form the vmware driver originally | |
| 21:09:30 | larsks | Okay. So effectively the best practice is not to use instance resource limits for anything, and rely on the per-service limits (e.g., cinder, neutron) where available. Is that accurate? | |
| 21:10:02 | sean-k-mooney | if you want to have interop between different public cloud then you could not rely on that feature existing | |
| 21:10:39 | sean-k-mooney | as an operator you can set them but it may cause issues for your users if you also expose the service qos apis | |