Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-23
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 dansmith regardless of the sharing mode
14:48:09 sean-k-mooney ya
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: Invert order of NUMA topology generation https://review.opendev.org/714701
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:26 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Allow 'hw:cpu_realtime_mask' to be omitted https://review.opendev.org/737026
17:32:26 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Tweak the 'cpu_realtime_mask' handling slightly https://review.opendev.org/461456
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.
17:33:57 sean-k-mooney it looks like its doing a depth frist traversal from the root with childern lexically sorted by uuid
17:35:05 sean-k-mooney efried: ya its fine ill figure it out. i might make it iterable jsut to make it spelper and immperment __repr__ for provier
17:35:24 sean-k-mooney *simpler and implement
17:51:49 sean-k-mooney efried: so ya i just need to add
17:51:50 sean-k-mooney def __iter__(self):
17:51:53 sean-k-mooney for uuid in self.get_provider_uuids():
17:51:55 sean-k-mooney yield self._find_with_lock(uuid)
17:52:42 sean-k-mooney but i might invert the logic an make get_provier_uuids use the iterator
17:53:15 sean-k-mooney it would avoid the need to call fine_with_lock twice once in get_provier_uuids and then again in the iterator
17:53:29 sean-k-mooney thanks for the pointer
18:01:16 efried sean-k-mooney: feel free to add me to review if you spin up something there.
18:03:14 efried Here's where that thing is used https://github.com/openstack/nova/blob/f1ebc15dfc8ffb7f23b2cb9879f0ca9376931a90/nova/scheduler/client/report.py#L1348-L1349 (and IIRC the reason it was written)
18:03:50 efried so whatever you change, please keep in mind that that ^ is going to run every periodic -- so don't slow it down too much :P
18:04:36 sean-k-mooney ya it should not be any slower
18:05:17 sean-k-mooney but sure ill add you to the review
18:07:51 stephenfin melwitt: could you hit this trivial requirements patch, please https://review.opendev.org/#/c/730960/ ?
18:25:04 openstackgerrit sean mooney proposed openstack/nova master: [WIP] make provider tree and proviers iterable https://review.opendev.org/737594
18:25:28 sean-k-mooney efried: that is the version where i have not inverted the logic ^
18:25:34 sean-k-mooney which im testign with http://paste.openstack.org/show/795116/
18:29:39 sean-k-mooney which if i execute it looks like this http://paste.openstack.org/show/795117/
18:31:19 efried ++

Earlier   Later