| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-23 | |||
| 11:22:18 | stephenfin | gibi: I'll trade https://review.opendev.org/#/c/736964/6 | |
| 11:23:04 | gibi | stephenfin: thanks | |
| 11:30:18 | openstackgerrit | Hervé Beraud proposed openstack/nova master: Remove lxml deprecated methods https://review.opendev.org/737472 | |
| 11:47:37 | nightmare_unreal | how can i get list of all compute nodes in a cell ? | |
| 11:59:32 | gibi | nightmare_unreal: nova-manage cell_v2 list_hosts | |
| 12:01:01 | nightmare_unreal | Yeah found it . I am now looking to do it programatically is nova-manage part of python-novaclient ? | |
| 12:08:51 | gibi | nightmare_unreal: no. the cell is a deployment level thing, it is not exposed via the REST API | |
| 12:09:35 | nightmare_unreal | Ah, okay !! | |
| 12:14:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Prevent libvirt driver to start on non Linux platform https://review.opendev.org/737508 | |
| 12:15:05 | gibi | stephenfin: ^^ | |
| 12:16:25 | openstackgerrit | Dirk Mueller proposed openstack/nova master: Switch from unittest2 compat methods to Python 3.x methods https://review.opendev.org/737511 | |
| 12:25:25 | gibi | stephenfin: responeded in https://review.opendev.org/#/c/736964 I don't get your comment about st_blocks | |
| 13:01:57 | stephenfin | gibi: Ah, ignore me: momentary lapse | |
| 13:07:51 | gibi | stephenfin: no worries. Thanks for reviewing | |
| 14:07:41 | aarents | dansmith: Let me know if those changes are ok: https://review.opendev.org/#/c/736169/ https://review.opendev.org/#/c/734776/ | |
| 14:14:53 | openstackgerrit | Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184 | |
| 14:25:56 | dansmith | aarents: looks like it from a high level.. will try to get back to those today if I can | |
| 14:27:19 | aarents | dansmith: thks | |
| 14:35:14 | sean-k-mooney | dansmith: so based on https://review.opendev.org/#/c/737548/ | |
| 14:35:30 | sean-k-mooney | dansmith: are we only going to then copy the image if we own it | |
| 14:35:45 | sean-k-mooney | or do you intned to have nova fall back to admin credetials | |
| 14:35:56 | dansmith | we're only going to be allowed to copy it if we own it at the moment, and we should not copy it with admin credentials | |
| 14:36:03 | dansmith | so basically, much less useful | |
| 14:36:16 | sean-k-mooney | ya that is what i was worreid about | |
| 14:36:26 | sean-k-mooney | but it also makes sense | |
| 14:36:32 | dansmith | the argument is that the owner of the image, despite being viewable, is "charged" to the owner for each location | |
| 14:36:39 | dansmith | although there isn't a resource usage report to convey this | |
| 14:36:49 | sean-k-mooney | yep | |
| 14:36:54 | dansmith | it seems to me that if an image is made public, charging the owner for it doesn't make much sense, | |
| 14:37:01 | sean-k-mooney | that is what i was wondering yesterday re billing | |
| 14:37:21 | sean-k-mooney | dansmith: the image can only be public if you are an admi | |
| 14:37:33 | dansmith | I think this is a very leaky concept unfortunately | |
| 14:37:37 | sean-k-mooney | communtiy images are also more or less public | |
| 14:37:51 | sean-k-mooney | those can be uploaded by non admins | |
| 14:38:06 | sean-k-mooney | but are not in the defualt image list i think | |
| 14:38:15 | dansmith | so my example is that you own an image, you push it to a site, get charged for it being there, I boot an instance from it, you delete it from that store, but my instance is still backed, so I'm still consuming the space, although glance can't reflect that, so I get it for free | |
| 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 | 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 | |