| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-03 | |||
| 12:27:55 | nicolasbock | Can I get it to execute? | |
| 12:28:01 | sean-k-mooney | so if you do nova server-migration-list 2aa3a324-bf22-4e0c-912a-d7c52f59f1fd does it have a migration object listed | |
| 12:28:53 | nicolasbock | No | |
| 12:30:10 | sean-k-mooney | oh hum strange. perhaps the migration has already been confirmed. | |
| 12:31:13 | sean-k-mooney | nicolasbock: efried might be able to help better the i if he is around | |
| 12:31:28 | nicolasbock | So I thought that `openstack resource provider allocation set` would allow me to update the DB | |
| 12:31:39 | nicolasbock | Thanks sean-k-mooney ! | |
| 12:32:06 | nicolasbock | But I am not using that command correctly since it complains about an incorrect 'allocation string format' | |
| 12:36:24 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/pike: libvirt: Use os.stat and os.path.getsize for RAW disk inspection https://review.openstack.org/607544 | |
| 12:37:16 | openstackgerrit | Matthew Booth proposed openstack/nova master: DNM: Run against mriedem's evacuate test https://review.openstack.org/604423 | |
| 12:44:15 | mdbooth | This is an interesting query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22AssertionError%3A%20u'host3'%20%3D%3D%20u'host3'%5C%22 | |
| 12:44:49 | mdbooth | I wonder why that started spiking only a few days ago: code change, or infra change? | |
| 13:03:06 | stephenfin | lyarwood: RE: https://review.openstack.org/588570 I'd been putting it off but will do that now. Will keep you posted | |
| 13:04:26 | lyarwood | stephenfin: cheers | |
| 13:06:26 | openstack | Launchpad bug 1209101 in OpenStack Compute (nova) "Non-public flavor cannot be used in created tenant" [High,Fix released] - Assigned to Sumanth Nagadavalli (sumanth-nagadavalli) | |
| 13:06:26 | s10 | How can I reopen bug https://bugs.launchpad.net/nova/+bug/1209101 ? It still exists. | |
| 13:07:02 | sean-k-mooney | s10: just change status and leave a comment with details | |
| 13:08:02 | s10 | sean-k-mooney: I've left comment, but I can't change status, all of them are grey. | |
| 13:08:38 | sean-k-mooney | s10: that said i dont think its nessisarly the same but. that was fixed in 2013 | |
| 13:08:47 | sean-k-mooney | its more likely a regression | |
| 13:08:59 | sean-k-mooney | are you seeing this on master? | |
| 13:09:51 | s10 | sean-k-mooney: Yes, this regression have never been fixed. I will write a comment about how to reproduce it. | |
| 13:10:56 | sean-k-mooney | well it was fixed and then reverted so this likely needs to be treated as more then a bug fix but rather as a blueprint/spec | |
| 13:13:21 | sean-k-mooney | the original bug fix predates microversions so i think a mini spec + microversion but would be required to alter the api behavior | |
| 13:13:57 | sean-k-mooney | bauzas: is ^ correct | |
| 13:14:27 | bauzas | context ? | |
| 13:14:56 | sean-k-mooney | private flavor are automatically expsed to new tenants | |
| 13:15:13 | openstack | Launchpad bug 1209101 in OpenStack Compute (nova) "Non-public flavor cannot be used in created tenant" [High,Fix released] - Assigned to Sumanth Nagadavalli (sumanth-nagadavalli) | |
| 13:15:13 | sean-k-mooney | because https://bugs.launchpad.net/nova/+bug/1209101 was reverted | |
| 13:15:55 | sean-k-mooney | sorry are not automatically exposed | |
| 13:18:35 | sean-k-mooney | bauzas: so context is if we want to chagne teh behavior of the api to auto grant access to the private flavor that would require a spec rather then being just a bug fix right as its an api change? | |
| 13:20:02 | bauzas | sean-k-mooney: IIUC, I'd tend to say yes, as it's a behavioural change | |
| 13:20:24 | bauzas | we don't really call the fact to not show private flavors as a "bug" | |
| 13:20:48 | bauzas | some people would also like to keep this behaviour I guess | |
| 13:21:17 | bauzas | and last but not the least, two OpenStack clouds could behave differently for the same request and list of flavors, which is not interop | |
| 13:21:26 | bauzas | HTH | |
| 13:34:10 | sean-k-mooney | s10: im just having lunch but based on bauzas confirmation rather then repoen the but i would suggest you file a nova spec. if you dont have time to do that i can see if i can do it later today but you have more context then i as to what you wanted to achive | |
| 13:39:28 | efried | nicolasbock: Still around? | |
| 13:40:59 | efried | nicolasbock: mriedem would be a better source of CLI syntax help, but I can tell you what the API call itself would need to look like. | |
| 13:41:42 | mnaser | does anyone know if CERN does pci passthrough on centos or ubuntu? | |
| 13:42:03 | dansmith | I thought they were all centos | |
| 13:43:05 | mnaser | i'm trying to figure out why pci passthrough isn't working | |
| 13:43:35 | mnaser | everything nova side is working ok, but the newly spawned qemu-kvm process is stuck spinning at 100% cpu, no console logs, libvirt qemu logs show nothing.. | |
| 13:44:32 | mnaser | so i'm a bit at a loss, not really sure where to go next | |
| 13:44:52 | s10 | sean-k-mooney: Basically, what I want to archive is to be able to provide tenants and ability to manage private flavors which they created. | |
| 13:46:13 | s10 | sean-k-mooney: But this will be more complicated than automatic flavor access add after private flavor creation... | |
| 13:46:43 | sean-k-mooney | s10: ok if that is the usecase then that should be relitvly simple to capture in a spec. ill write up a spec. | |
| 13:47:16 | sean-k-mooney | s10: oh why should we not jsut need to allow the teant that created teh flavor to have acess to it automatically? | |
| 13:48:17 | sean-k-mooney | for interop reasons we will need a microversion bump but that is just a mechanical sideeffect not germain to the feature | |
| 13:53:21 | s10 | sean-k-mooney: I want them to have access to created flavor automatically because there is no RBAC in nova for private flavors. Flavors don't have an owner. I can't only allow tenants to run flavor-access-add for "their" flavors :( | |
| 13:58:12 | mnaser | ou | |
| 13:58:17 | mnaser | i wonder if this has to do with using lvm local storage | |
| 13:58:54 | mnaser | and the qemu user not being able to access it | |
| 13:58:55 | mnaser | hmm | |
| 13:59:30 | mnaser | yup, it can't access it | |
| 14:00:15 | mnaser | would it be a responsibility of nova to setup permissions of volumes under lvm so that the qemu user can read it? | |
| 14:02:59 | mdbooth | I just ran a git bisect to try to find out why the incidence of test_parallel_evacuate_with_server_group failure went from occasional to almost 50% in the last few days, and the culprit is my patch from the other day: https://review.openstack.org/#/c/604859/ | |
| 14:03:06 | mdbooth | I still consider this a feature :) | |
| 14:14:43 | mriedem | dansmith: did you know there was a cinder_img_volume_type metadata key which can be used to create a bootable volume with a specific volume type? https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html#volume-types | |
| 14:15:11 | mriedem | so technically people today could boot from volume from an image with that metadata and get what they wanted instead of passing a volume type to nova - clunky i know | |
| 14:15:14 | dansmith | on the image | |
| 14:15:18 | mriedem | yeah, | |
| 14:15:22 | dansmith | I did not know that, no | |
| 14:15:49 | mriedem | likely also means that we need to make a decision in the compute API if the user specifies a volume type and the source image has that metadata key/value, which do we pick? or do we 400? | |
| 14:16:42 | mriedem | probably need to know what cinder does in that same case | |
| 14:16:49 | mriedem | smcginnis: do you know off the top of your head? ^ | |
| 14:17:06 | dansmith | seems to me like if they ask for something on the boot request, that always wins | |
| 14:17:07 | dansmith | like, we have a default type, and there can be a default for an image, | |
| 14:17:10 | smcginnis | If you explicitly provide a type, I believe we will give that priority over the image property. | |
| 14:17:18 | dansmith | but if they ask for something specific at the time, I would expect they want the one they asked for | |
| 14:17:33 | mriedem | yeah that's what i'd expect too | |
| 14:17:52 | smcginnis | So fallback can be to have the volume type stuffed in the image properties, but that should not change the primary usage of someone saying specifically what they want. | |
| 14:20:44 | mnaser | yup. that was the issue | |
| 14:20:57 | mnaser | if you use lvm on centos with nova, the volumes are created under user 'root' | |
| 14:21:04 | mnaser | so qemu process cant touch them and it cant boot | |
| 14:21:12 | mnaser | is this technically a nova bug? | |
| 14:21:41 | mnaser | (aka the devices on the system /dev/vg_foo/vmuuid_disk are root:root, qemu-kvm runs on qemu:qemu) | |
| 14:23:05 | nicolasbock | Hi efried I am still here | |
| 14:25:29 | efried | nicolasbock: So looking at the manual (https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-allocation-set) it appears as though you're going to want multiple --alocation params... | |
| 14:25:42 | openstack | Launchpad bug 1746972 in OpenStack Compute (nova) "After setting the password failed, the VM state is set to error" [Undecided,Confirmed] | |
| 14:25:42 | s10 | mriedem: Can we remove line https://github.com/openstack/nova/blob/stable/rocky/nova/compute/manager.py#L3669 ? It causes bug https://bugs.launchpad.net/nova/+bug/1746972 . I don't believe that error in set-admin-password on running instance should put instance in error state and require cloud admin intervention to reset instances state or that user should abandon and remove this vm. | |
| 14:25:54 | nicolasbock | Yes, that's my reading too efried | |
| 14:26:03 | nicolasbock | But I don't understand what the other parameters should look like | |
| 14:26:07 | efried | nicolasbock: I *think* each should look like --allocation rp=$rp_uuid,$rc=$amount | |
| 14:26:10 | dansmith | mnaser: what do you want nova to do? chown them? afaik, it doesn't know what user qemu will run as | |
| 14:26:23 | openstackgerrit | Merged openstack/nova stable/pike: nova-status - don't count deleted compute_nodes https://review.openstack.org/604788 | |
| 14:27:00 | nicolasbock | Ok. What I don't get is why I need a resource-class in there as well. I don't want anything to update in terms of resource classes | |
| 14:27:26 | efried | nicolasbock: Oh, but you do :) | |
| 14:27:34 | nicolasbock | I do? | |
| 14:27:47 | efried | nicolasbock: I guess it's obvious to me because I know what the REST payload looks like, but come to think of it, it makes sense how you're thinking about it. | |
| 14:28:12 | nicolasbock | Maybe I am not looking at resource classes correctly | |
| 14:28:20 | efried | nicolasbock: See, the allocations in the API are a hierarchical structure like resource provider => resource class => amount | |
| 14:28:27 | nicolasbock | But the way I am thinking about them is that they specify things like memory and CPU cores | |
| 14:28:35 | nicolasbock | Ok | |
| 14:28:55 | efried | And also the CLI (and the API it's using) is designed to fully *replace* allocations, not like edit pieces of them. | |
| 14:29:00 | efried | So given that... | |
| 14:29:10 | efried | nicolasbock: You should do `openstack resource provider allocation show $instance_uuid` | |
| 14:29:23 | efried | Which should give you allocations in three-ish resource classes | |
| 14:29:34 | efried | nicolasbock: can you pastebin me that output? | |
| 14:29:59 | dansmith | you know what would be awesome | |