| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-23 | |||
| 14:38:45 | dansmith | it doesn't matter, if I can see an image I don't own, and can boot instances from it, then I can consume resources you're charged for | |
| 14:39:20 | sean-k-mooney | ya so that model does nto really work though | |
| 14:39:33 | sean-k-mooney | are you still chared for the glance image after its deleted | |
| 14:39:43 | sean-k-mooney | if you have vms that were booted form it? | |
| 14:39:54 | sean-k-mooney | that seams like double billing | |
| 14:40:00 | dansmith | the question is whether *other* users have instances | |
| 14:40:10 | sean-k-mooney | well even if the dont | |
| 14:40:17 | dansmith | I would hope that if you try to remove an image from a store, you fail if there are instances booted from it | |
| 14:40:18 | sean-k-mooney | if you upload an iamge boot a vm and delete the image | |
| 14:40:26 | sean-k-mooney | you should not be changed for the iamge storage right | |
| 14:40:44 | dansmith | which means if I push an image to an edge site and am charged for it, and someone *else* boots an image to pin it there, I can't delete it and stop being billed until this other user I don't know stops using it | |
| 14:41:00 | sean-k-mooney | dansmith: removing a image in genrall we would not block removing an image form the store maybe | |
| 14:41:23 | dansmith | in that case, we leak it and either have no way to delete it later, or have no way to charge it to anyone | |
| 14:41:32 | sean-k-mooney | the glance store concept is also problemeatinc in this regrad | |
| 14:41:34 | dansmith | it's broken in one of three ways I think | |
| 14:42:10 | sean-k-mooney | well for the file backend once i boot a vm form it i dont need the glance copy right | |
| 14:42:25 | sean-k-mooney | for the rbd backedn or cinder backend then that is different | |
| 14:42:38 | dansmith | yeah, I'm talking about rbd or any other managed shared backend type | |
| 14:42:40 | sean-k-mooney | because we are doing a shallow snapshot fo the new volume | |
| 14:43:02 | dansmith | but the copy-to-store functionality was added for this rbd edge case specifically | |
| 14:43:19 | sean-k-mooney | but i dont think i should be change for that backing volume since im paying for the space via the vm | |
| 14:43:51 | sean-k-mooney | and in the case where you use my iamge you are paying for the space with your image | |
| 14:43:52 | dansmith | that's another good point, I'm not sure how that works either.. | |
| 14:44:00 | sean-k-mooney | because without this we would have flatened it | |
| 14:44:15 | dansmith | basically, I thought image billing was done by just listing the images and counting up the image_size attributes, which would not include the multiple copies | |
| 14:44:25 | dansmith | which I understand might not be right, in terms of actual bytes used | |
| 14:44:42 | sean-k-mooney | dansmith: that i assuemd would be the case too | |
| 14:45:05 | sean-k-mooney | multi sotre potentally changes that | |
| 14:45:12 | dansmith | yeah | |
| 14:45:16 | sean-k-mooney | but i dont think it should nessisarly | |
| 14:45:43 | sean-k-mooney | is this something we would want to expose to an operator via a nova config option | |
| 14:46:01 | dansmith | well, one argument is you could be consuming 10x your image size in multiple stores, so I get that, but... it all breaks down somewhere if multiple users can see an image | |
| 14:46:10 | sean-k-mooney | so they could choie if we do the copy via admin or not or no | |
| 14:46:33 | dansmith | I think what will have to happen is we will have some property on an image that determines if it's a public free-for-all image, and nova will only copy it if that attribute is set (or they are the owner) | |
| 14:47:15 | sean-k-mooney | it would have to be supported on shared, public and community images | |
| 14:47:27 | sean-k-mooney | shared are shared by adding other tenats to a member list | |
| 14:47:48 | sean-k-mooney | comunity is visable to everyone but only in the default image list if you are added to the image member-list | |
| 14:47:56 | dansmith | I think it would be any image with that set, and then we'd use admin creds to copy it | |
| 14:48:09 | sean-k-mooney | ya | |
| 14:48:09 | dansmith | regardless of the sharing mode | |
| 14:48:22 | sean-k-mooney | that should work | |
| 14:48:33 | sean-k-mooney | i was wondigin if we need to chagne the error code however | |
| 14:48:43 | dansmith | I don't like it because it means nova will never be able to decide if you can boot an image on a node until it is starting to build it | |
| 14:48:56 | dansmith | since only the compute node knows what rbd store it is connected to (without a lot more work) | |
| 14:49:01 | sean-k-mooney | so if glance should assert you are allows to copy it by virute fo being in the member list or not | |
| 14:49:02 | dansmith | but yeah, better than nothing | |
| 14:49:50 | sean-k-mooney | dansmith: does this affct the ablity to boot on a node. i guess if we have that never donwlaod config? | |
| 14:49:59 | sean-k-mooney | otherwise we could fall back right | |
| 14:50:11 | sean-k-mooney | if we cant do an import and just flatten the image | |
| 14:50:22 | dansmith | import and flatten is never the answer | |
| 14:50:41 | sean-k-mooney | well that is what we woudl do today right | |
| 14:50:50 | dansmith | yes | |
| 14:51:00 | dansmith | never the *right* answer I mean :) | |
| 14:51:08 | sean-k-mooney | :) | |
| 14:51:31 | sean-k-mooney | the behavior of the new config option is to treate the need to flatten as an error right | |
| 14:51:35 | sean-k-mooney | leadign to a reshdule | |
| 14:52:05 | dansmith | well, (a) we never reschedule anymore, we consume one of the alternates, but (b) yes, the workaround makes it an error | |
| 14:52:25 | sean-k-mooney | dansmith: sorry yes you are right about the alternive hosts | |
| 14:52:47 | sean-k-mooney | dansmith: although that does cause issues for mutlicreate and anti affinity groups but thats another matter | |
| 14:53:09 | dansmith | we also can't download it and upload it as a new base and add it to the image as a location because... we don't own the image and if we did that as admin, we'd start charging the owner, which is a roundabout way to do what we could already do as admin | |
| 14:53:34 | sean-k-mooney | dansmith: well i was not suggesting uplaoad as a new location | |
| 14:54:01 | sean-k-mooney | i ment jus tdo want we do today download it localy the stream it into the rbd volume | |
| 14:54:24 | sean-k-mooney | which sucks because we loose copy on write | |
| 14:54:29 | dansmith | no, I know, but that is never the right answer.. I'm saying we couldn't make nova do the slightly smarter thing of uploading it as a new base image | |
| 14:54:44 | sean-k-mooney | dansmith: ah right | |
| 14:54:58 | dansmith | import and flatten means you consume N*size for N instances, which defeats the whole point and consumes a lot of expensive storage | |
| 14:55:10 | sean-k-mooney | well i think the image metadat property for allow_multistore_copy=true|false makes sense | |
| 14:55:54 | sean-k-mooney | what would the default be. i would like it to be true but i guess it has to be false if not set | |
| 14:56:52 | dansmith | I'm having a hard time understanding how "public" isn't a good enough flag to use, honestly | |
| 14:57:11 | dansmith | unsure about shared/community, but.. public images for sure seem like they should be copyable | |
| 14:57:14 | sean-k-mooney | i guess its allow_admin_multistore_copy too rather then allow_multistore_copy | |
| 14:57:28 | sean-k-mooney | ya so maybe it coudl be based on visablity | |
| 14:57:36 | sean-k-mooney | e.g. the default | |
| 14:57:53 | sean-k-mooney | so true for public by defualt not sure baout shared or commuity iehter | |
| 14:59:40 | sean-k-mooney | shared i would be tempetd to say false by default and comunnity false would be conservitive but true might make sense | |
| 15:00:00 | sean-k-mooney | dansmith: the other angel to this is geofenceing | |
| 15:00:51 | sean-k-mooney | dansmith: moving it to another store might move it to another geo which may be an export violation altough in the curent case we do that indirectly so not sure it a problem or not | |
| 15:01:33 | dansmith | that's a glance policy enforcement problem separate from this I think | |
| 15:01:58 | sean-k-mooney | ya i think so too | |
| 15:02:37 | sean-k-mooney | ok i better go get some work done. thanks for bring me up to speed o/ | |
| 15:03:39 | dansmith | yup | |
| 16:11:39 | gibi | public announcement: I will be off tomorrow but will be back on Thurstday | |
| 16:12:03 | sean-k-mooney | gibi_off: enjoy | |
| 16:12:42 | gibi_off | sean-k-mooney: thanks | |
| 17:23:35 | sean-k-mooney | efried: not sure if you are about but do you know if there is any reason we have not made provider trees or proviers to be iterable over there childeren? | |
| 17:24:45 | sean-k-mooney | i know that is not stirctly need but it would be nice to be able to pretty print them and it makes some operation nicer | |
| 17:25:43 | efried | Yes, there's a function to iterate over them in order. We use it in the master update_provider_tree loop. | |
| 17:26:09 | sean-k-mooney | efried: oh ok we just did not implement __iter__ | |
| 17:26:24 | efried | I would believe that. | |
| 17:26:28 | efried | It recently came up here: https://review.opendev.org/#/c/719163/18/nova/scheduler/client/report.py | |
| 17:27:17 | sean-k-mooney | that gives use the provider uuids but not the provider objects but ok i was looking at that | |
| 17:28:05 | sean-k-mooney | efried: thanks im trying to think how i will go about the transfroamtion for modeling nuam in placement and i want a nice way to visualise the tree | |
| 17:32:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Remove '_numa_fit_instance_cell_with_pinning' https://review.opendev.org/714703 | |
| 17:32:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Invert order of NUMA topology generation https://review.opendev.org/714701 | |
| 17:32:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Tweak the 'cpu_realtime_mask' handling slightly https://review.opendev.org/461456 | |
| 17:32:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Allow 'hw:cpu_realtime_mask' to be omitted https://review.opendev.org/737026 | |
| 17:33:08 | efried | I thought gibi_off wrote some kind of tool to prettyprint those trees. | |
| 17:33:17 | sean-k-mooney | maybe | |
| 17:33:37 | efried | I don't have it in front of me, but looking provider_tree.py for that iterator function. | |
| 17:33:53 | efried | It's not __iter__ but I'm pretty sure I made a getter that gives them to you in a predictable order. | |