| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-03 | |||
| 12:12:38 | sean-k-mooney | mdbooth: was lookin at an edgecase recently where if cleanup on the source fail we dont update the vm host | |
| 12:14:29 | sean-k-mooney | nicolasbock: e.g. when you finish migrating the instace if the post migrate job on the source node failts to say unplug a vif we fail before we update the instace db record to refect that the vm is running on the new node | |
| 12:14:49 | sean-k-mooney | mdbooth: did you ever proposea a patch for ^ | |
| 12:15:12 | mdbooth | sean-k-mooney: Probably. | |
| 12:17:27 | sean-k-mooney | nicolasbock: are the placement allocation currently associated with the vm correct for the host it is actully on | |
| 12:17:45 | sean-k-mooney | e.g. if you ignore the db host value and actully check the vms location | |
| 12:18:00 | mdbooth | sean-k-mooney: Trying to parse your comment here: https://review.openstack.org/#/c/605436/5/nova/compute/manager.py@1447 | |
| 12:18:18 | mdbooth | Are you saying we can release the lock there? | |
| 12:18:25 | mdbooth | Or yield the context manager there? | |
| 12:18:35 | mdbooth | Or something else, because neither of ^^^ would be correct. | |
| 12:18:48 | nicolasbock | The VM is running on `6cbb84b0-02f4-4ee3-9df2-151475b1effe` | |
| 12:19:03 | nicolasbock | But placement says that it's on `57b0e4d5-3a3e-4cf3-ba8c-b88c8ce4679b` | |
| 12:19:09 | sean-k-mooney | mdbooth: im saying if we dont have a lock when we invoke that line the db request could cause use to yeild causeing a race | |
| 12:19:32 | mdbooth | Ah, *eventlet* yield | |
| 12:19:37 | mdbooth | Ok. | |
| 12:19:54 | sean-k-mooney | e.g. this is the thing that definetly needs to be in the critcal section of the lock | |
| 12:20:01 | nicolasbock | I ran `openstack server show 2aa3a324-bf22-4e0c-912a-d7c52f59f1fd` | |
| 12:20:15 | nicolasbock | and `openstack resource provider allocation show 2aa3a324-bf22-4e0c-912a-d7c52f59f1fd` | |
| 12:21:06 | sean-k-mooney | mdbooth: ya re reading that was not clear | |
| 12:21:53 | sean-k-mooney | nicolasbock: is 57b0e4d5-3a3e-4cf3-ba8c-b88c8ce4679b the source or destination of the migration | |
| 12:22:23 | sean-k-mooney | nicolasbock: im assume the destination correct? | |
| 12:22:36 | sean-k-mooney | sorry source | |
| 12:23:07 | nicolasbock | I don't know what happened, but I would guess that it is the source | |
| 12:23:27 | nicolasbock | Sorry, I am not sure I completely grasp the terminology of source and destination | |
| 12:23:43 | sean-k-mooney | ya so the resouce being used on 6cbb84b0-02f4-4ee3-9df2-151475b1effe are likely still owned by the migration object in placement | |
| 12:24:44 | nicolasbock | What's the migration object? | |
| 12:26:21 | sean-k-mooney | when you do a migration we create a migration record that we use to calim resouces on the destination host then when the vm is move we use a special atomic oepration in the placemnt api to change the allocation consumer form the migration recordds uuid to the vms uuid | |
| 12:27:23 | nicolasbock | So you are saying that that atomic operation wasn't executed? | |
| 12:27:30 | sean-k-mooney | yes | |
| 12:27:35 | nicolasbock | Ok | |
| 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 | |