| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-17 | |||
| 16:50:36 | sean-k-mooney | TheJulia: well that is where they are doing it wrong | |
| 16:50:53 | sean-k-mooney | nova has ways to do access contol on flaovr or via aggreates based on tenatns | |
| 16:51:18 | TheJulia | arne_wiebalck: ^^^ fyi, you might find this interesting or super frustrating | |
| 16:51:52 | sean-k-mooney | nova has the idea of private flavors so you can create 1 flaovr an choose what tenats can see it | |
| 16:52:31 | TheJulia | asked the super large operator, I think cern is operating with something like like ~130-140 distinct SKUs across their fleet, some of it is private skus for hyper specific needs/purposes, others are general from what I understand. I believe they've mentioned some crazy number of flavors as well. | |
| 16:53:56 | TheJulia | ugh, apparently the super large operator has lots of downstream patches wrapped around flavors/classes, so their huge numbers are not exactly valid for this discussion since we don't understand the entire story/composition there. | |
| 16:54:44 | sean-k-mooney | i can see them doing thing like adding a customer specific resouce class so they can dedicate specifc pools to them | |
| 16:54:55 | sean-k-mooney | but that is not how its ment to be done | |
| 16:55:07 | TheJulia | sean-k-mooney: I _think_ cern has mentioned them doing private flavors before, but that it adds up for admins to dump the list out | |
| 16:55:46 | mnaser | fwiw openstack cli shows public flavors only by default, even for admins | |
| 16:55:52 | mnaser | you have to explicitly give it --private to get those | |
| 16:56:10 | dansmith | sean-k-mooney: exactly | |
| 16:56:26 | sean-k-mooney | well it can but when you create private flavor you dont create the same flavor multiple times for different tenatnts. you create it once and add the teant 1:1 to the existing flavor | |
| 16:57:09 | sean-k-mooney | mnaser: that is true today but i actully want to change how that work. i want ti to be private if you add a tenat too the flavor acess list and public if not | |
| 16:57:19 | dansmith | and again, if you want thousands of different configs, you'll either end up with thousands of flavors, or thousands of instances with whatever bespoke thing you've asked for, it will just be far less discoverable | |
| 16:57:32 | sean-k-mooney | mnaser: at the moemnt you cant change the private public status and that causes pain | |
| 16:57:54 | dansmith | so people having "all the same flavor" which have been individually hand-managed to be different is just going to end up with that madness being hidden | |
| 16:58:06 | mnaser | sean-k-mooney: yeah the move private => public is a bit harsh but im not sure why/how/when it's been the case. i would have never touched the db and manually changed that field before. ever. | |
| 16:58:16 | dansmith | which is kinda the point of what we're doing here -- trying to manage N things as a unit, where N is too large for any human to do manually | |
| 16:59:07 | mnaser | also, i agree about the comments wrt instance type shouldn't mean different things, it sucks to manage it at scale, but, there's tons of ways you can (relatively easily) automate something like this | |
| 16:59:10 | mnaser | say, this ansible | |
| 16:59:10 | sean-k-mooney | mnaser: its useful to go from public to private too for decomisioning old flavors | |
| 16:59:30 | mnaser | sean-k-mooney: yes, that's true too. i'm sure someone out there knows the real reason behind it | |
| 16:59:58 | mnaser | i have risked moving private to public, but not public to private as that seemed a little more intense in terms of the things that can break | |
| 17:00:55 | sean-k-mooney | mnaser: yep i discussed this with gmann a while back and its on the list of things to "clean up" in a future microverions but we have not put up a blueprint for it yet | |
| 17:01:36 | sean-k-mooney | mnaser: when private flavors where added the ability to move between them was just never adressed so in that regard its a half implemnted feature | |
| 17:01:58 | sean-k-mooney | but its one i think we can improve. | |
| 17:02:36 | sean-k-mooney | dansmith: i guess the problem is that right now they are managing the N things with kickstart | |
| 17:03:02 | sean-k-mooney | and not tacking advantage of the abstractions provided by openstack | |
| 17:03:08 | dansmith | sean-k-mooney: I thought the tenants were doing that, but yeah | |
| 17:04:35 | TheJulia | sean-k-mooney: no, they are only using kickstart files to rebuild machines | |
| 17:04:48 | TheJulia | because they simply need a way more complex running configuration | |
| 17:05:27 | sean-k-mooney | TheJulia: right but if openstack coudl provide that config would they use it or whould they keep doing it the way they are now so that they can support non openstack envs | |
| 17:07:05 | sean-k-mooney | by the way i do not use ironic that often so im not sure what capablity you can use via ironic direct vs ironic via nova but even though ironic direct can leverage ironic to do raid and bios config today they are not using it | |
| 17:07:50 | TheJulia | sean-k-mooney: in a perfect world, they would want to be able to re-use the same config or formatting instead of having to go through a bunch of additional steps or abstractions to just get the job done for the day. The point here is they want everything through openstack because of the single pane of glass benefit. | |
| 17:08:42 | sean-k-mooney | TheJulia: right which is why im confused that they would reimage the machine since that is the opisiste of doing everythin vis openstack | |
| 17:09:35 | dansmith | sean-k-mooney: they want to put a break statement anywhere they want in the workflow to use as much or little openstack as they want | |
| 17:09:46 | TheJulia | sean-k-mooney: because the constraints in which openstack puts them with are insufficent to meet their needs of their business for their 10, 100, 1000 machines they may ask for on a given day | |
| 17:10:29 | gmann | mnaser: sean-k-mooney: on flavor things, its in list to cleanup - item 10 in https://etherpad.opendev.org/p/nova-api-cleanup | |
| 17:10:59 | gmann | which is basically get rid of is_public thing and every flavor is private and accessible to allowed tenants only | |
| 17:11:01 | sean-k-mooney | gmann: yep i knew you added it to the list but i did not have it bookmarked | |
| 17:11:31 | sean-k-mooney | gmann: that is not what i had in mind | |
| 17:12:01 | gmann | and that bug adding public flavor things is since liberty - https://bugs.launchpad.net/nova/+bug/1361476 | |
| 17:12:01 | openstack | Launchpad bug 1361476 in OpenStack Compute (nova) "flavor access create should check public/private first" [Low,Fix released] - Assigned to Sergey Nikitin (snikitin) | |
| 17:12:03 | sean-k-mooney | gmann: i was thinking every flavor would be public unless you addd a tenatn via flavor access in which case it would only be visable to those that were in the list | |
| 17:12:45 | gmann | i sex, what is is_public default? | |
| 17:12:52 | gmann | sec | |
| 17:13:06 | sean-k-mooney | it defaults to public/true | |
| 17:13:13 | sean-k-mooney | so i wanted to keep that behavior | |
| 17:13:40 | sean-k-mooney | but instead of seting it to public or private explictly base it on the flavor acess info | |
| 17:14:19 | gmann | yeah https://github.com/openstack/nova/blob/6ed556f4adfd8a98fae2e91204f1ce0484f5dd9d/nova/api/openstack/compute/flavor_manage.py#L69 | |
| 17:14:59 | sean-k-mooney | e.g. is_public = "select count(*) form flavor_access where flavor_id = $whatever" == 0 | |
| 17:15:06 | gmann | right, keeping the same behavior but allowing it to add tenant access and so does list | |
| 17:15:43 | openstackgerrit | Sean McGinnis proposed openstack/nova master: Use unittest.mock instead of third party mock https://review.opendev.org/714676 | |
| 17:16:21 | sean-k-mooney | right so you start with a public flaovr. then if you add a tenant to the acess list it "private" and only that tenatn and an admin can see it | |
| 17:16:30 | sean-k-mooney | if you remove them it avaiable to all again | |
| 17:17:29 | sean-k-mooney | nova flavor-access-list --flavor <my public flavor> should have eitehr retruned None | |
| 17:17:48 | sean-k-mooney | so the "fix" to https://bugs.launchpad.net/nova/+bug/1361476 in my view was incorrect | |
| 17:17:48 | openstack | Launchpad bug 1361476 in OpenStack Compute (nova) "flavor access create should check public/private first" [Low,Fix released] - Assigned to Sergey Nikitin (snikitin) | |
| 17:18:16 | sean-k-mooney | but it was also done in liberty so its not really important right now | |
| 17:18:45 | gmann | yeah, its been long it is like that | |
| 17:19:14 | sean-k-mooney | and since we use or dont use microverions with osc eveyone that use osc does not expect the new behavior | |
| 17:19:28 | sean-k-mooney | new beign "2.7" | |
| 17:19:36 | sean-k-mooney | they get the old behavior where its not an error | |
| 17:20:07 | sean-k-mooney | so you can add flavor access even today you jsut use the old microverion | |
| 17:20:10 | gmann | is it not max version behavior in osc? | |
| 17:20:17 | sean-k-mooney | no min | |
| 17:20:19 | gmann | by default | |
| 17:20:27 | sean-k-mooney | so by defcault everythin uses 2.1 | |
| 17:20:48 | gmann | i remember novaclient is default to min but not sure about osc | |
| 17:21:04 | sean-k-mooney | gmann: other way around novaclinet uses latest | |
| 17:21:08 | sean-k-mooney | osc uses min | |
| 17:21:34 | sean-k-mooney | so nova clients behavior change depending on the clinet version and api you are talking too | |
| 17:21:36 | gmann | ah yeah otherway around. | |
| 17:21:47 | sean-k-mooney | osc is consitent regardless of the verion or cloud | |
| 18:02:37 | melwitt | sean-k-mooney: do you know of a way of changing a guest's video model other than virsh editing it? context is the cirrus-vga type got deprecated https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.2_release_notes/deprecated_functionality#deprecated-functionality_virtualization and can result in bad looking low res vnc console | |
| 18:04:52 | melwitt | it used to look fine prior to an upgrade to stein, then looked messed up. so I'm trying to determine how users could update their existing instances | |
| 18:24:54 | sean-k-mooney | melwitt: yes you can use hw_video_model in the image metadata | |
| 18:25:14 | sean-k-mooney | melwitt: i always use virtio | |
| 18:25:17 | melwitt | sean-k-mooney: ok, how to get an already existing instance to pick that up without rebuilding it? | |
| 18:25:32 | sean-k-mooney | melwitt: db edit | |
| 18:25:57 | melwitt | ok, so db edit instead of a virsh edit.. and then hard reboot the instance? | |
| 18:26:03 | sean-k-mooney | add img_hw_video_memory=virtio in the system_metadata table | |
| 18:26:08 | sean-k-mooney | yep | |
| 18:26:30 | melwitt | ok. guh | |
| 18:26:37 | sean-k-mooney | img_hw_video_model=virtio not memory | |
| 18:27:24 | sean-k-mooney | melwitt: is this for a customer or you? | |
| 18:27:26 | melwitt | we're defaulting to the deprecaed 'cirrus' on master even, so I think that needs to change https://github.com/openstack/nova/blob/6ed556f4adfd8a98fae2e91204f1ce0484f5dd9d/nova/virt/libvirt/config.py#L1949 | |
| 18:27:33 | melwitt | customer | |
| 18:27:46 | sean-k-mooney | ah then rebuild | |
| 18:28:25 | sean-k-mooney | we also just added docs for this in OSP and no one metioned the deprecate or asked us to not sure that docs appies | |
| 18:28:46 | sean-k-mooney | that is for base rhel not the advance virt stream which we use in osp | |
| 18:28:47 | melwitt | sean-k-mooney: do you happen to know which value would be an appropriate default being that cirrus is deprecated? the choices in the aforementioned 8.2 release notes give choices of stdvga, virtio-vga, or qxl | |
| 18:29:19 | sean-k-mooney | the only one of those 3 that would work is qxl that doc is for using kvm directly | |
| 18:29:32 | sean-k-mooney | *libvirt not kvm | |
| 18:29:34 | melwitt | ah good to know | |
| 18:29:56 | melwitt | yeah, the customer is working around by setting hw_video_model=qxl but obvs that only works for new instances | |
| 18:30:09 | melwitt | *setting in image meta | |
| 18:30:41 | sean-k-mooney | what release is it | |
| 18:30:44 | sean-k-mooney | https://bugzilla.redhat.com/show_bug.cgi?id=1714508 | |