| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-18 | |||
| 19:23:59 | lyarwood | sean-k-mooney: ^ awful hacks, no idea if that would even work but there we go. This would actually be easier to do if this was a playbook... | |
| 19:24:16 | noonedeadpunk | Ok, I see. Just wondering if it makes sense to look into it to propose a patch | |
| 19:25:47 | noonedeadpunk | As there's no blockers which are aware for everyone, will try that out | |
| 19:26:27 | sean-k-mooney | noonedeadpunk: its an api change which would require a microverion bump and a spec | |
| 19:26:36 | sean-k-mooney | so it cant be done as a bug fix | |
| 19:26:40 | sean-k-mooney | https://docs.openstack.org/api-ref/compute/?expanded=remove-flavor-access-from-tenant-removetenantaccess-action-detail#flavors-access-flavors-os-flavor-access | |
| 19:26:56 | sean-k-mooney | the flavor acess api is what is normally used instead | |
| 19:28:44 | noonedeadpunk | sean-k-mooney: the thing I'm missing is transition from is_public: true to is_public: false.... | |
| 19:29:25 | sean-k-mooney | yep | |
| 19:29:31 | noonedeadpunk | but yeah, it needs api version bump... | |
| 19:30:03 | noonedeadpunk | anyway thanks for answering:) | |
| 19:30:20 | sean-k-mooney | noonedeadpunk: most flavor fileds are imuntable after its created | |
| 19:31:02 | sean-k-mooney | the update endpoint only supports updating the description | |
| 19:31:04 | noonedeadpunk | I can understand about flavor properties, as it will mix up isntances | |
| 19:31:27 | sean-k-mooney | https://docs.openstack.org/api-ref/compute/?expanded=update-flavor-description-detail#update-flavor-description | |
| 19:31:45 | noonedeadpunk | but is_public is kinda visability thing, which should be safe to update in that terms | |
| 19:32:03 | sean-k-mooney | in theory yes. | |
| 19:32:38 | sean-k-mooney | although updating it wont change the status of the is_public flag in the embded flavor in an instnace | |
| 19:32:42 | gmann | but it might cause restriction access to few tenants which are not in access list. | |
| 19:33:31 | openstack | bug 1844929 in OpenStack Compute (nova) "grenade jobs failing due to "Timed out waiting for response from cell" in scheduler" [High,Confirmed] https://launchpad.net/bugs/1844929 | |
| 19:33:31 | openstackgerrit | melanie witt proposed openstack/nova master: DNM: try to get some debug info for bug 1844929 https://review.opendev.org/701478 | |
| 19:34:03 | sean-k-mooney | gmann: well this is not using the os-flavor-acces api | |
| 19:34:17 | sean-k-mooney | this is setting the is_public flag in the flavor itself | |
| 19:34:34 | sean-k-mooney | the os-flavor-acces api is normally what peopel shoudl use | |
| 19:34:53 | sean-k-mooney | so to make a flavor private you just add acess to only the admin/service project | |
| 19:35:00 | sean-k-mooney | then no other tenats can see it | |
| 19:35:01 | gmann | yeah but we restrict the public flavor to process in flavor-access api | |
| 19:35:30 | gmann | yeah, removing all other tenants make it private | |
| 19:36:14 | sean-k-mooney | noonedeadpunk: does ^ makes sense | |
| 19:37:00 | sean-k-mooney | noonedeadpunk: is_public on the flavor is a hold over from before we had per tenant contol over flaovr visablity | |
| 19:37:06 | noonedeadpunk | hm, let me check that | |
| 19:38:02 | noonedeadpunk | (actully deploy latest sandbox and test) | |
| 19:38:40 | sean-k-mooney | lyarwood: looking at https://github.com/openstack/devstack-plugin-ceph/blob/master/devstack/lib/ceph#L1213-L1251 it looks like ceph is not in the devstack slice | |
| 19:38:50 | sean-k-mooney | so stop devstack@* should be ok | |
| 19:39:34 | sean-k-mooney | you would still have to do "killall qemu" or use virish stop on all active domains too to stop the rbd device in use error | |
| 19:39:37 | lyarwood | sean-k-mooney: right and I don't think we deploy anything on the subnode in this case anyway | |
| 19:39:46 | gmann | only thing is you would not be able to add projects or list access info on public flavor | |
| 19:40:23 | sean-k-mooney | gmann: you can use the flavor acess api to do that | |
| 19:40:40 | sean-k-mooney | horizon allows you to take a standard public flavor and add tenants too it | |
| 19:41:08 | gmann | sean-k-mooney: no, after 2.7 add project is restricted on non-public and list access is for non-public only from stating | |
| 19:41:19 | sean-k-mooney | gmann: i tought the os-flaovr-acess api basically ignored the is_public atribte | |
| 19:41:29 | gmann | https://github.com/openstack/nova/blob/c9f5b583b6072f542d1757e35fd6305b9698496a/nova/api/openstack/compute/flavor_access.py#L50-L75 | |
| 19:41:44 | sean-k-mooney | gmann: right so if you use an older microversion then what happens | |
| 19:42:13 | gmann | with older than 2.7 yes you can add. | |
| 19:42:39 | sean-k-mooney | i suspect horizon is using older then 2.7 | |
| 19:42:52 | sean-k-mooney | why did we make that change? | |
| 19:43:27 | gmann | well, public means for everyone so we do not really need to add access things right | |
| 19:44:05 | sean-k-mooney | gmann: basicaly i tought we effectivly deprecated is_public and ignored it | |
| 19:44:21 | sean-k-mooney | gmann: so if you use falvor acess it effectivly became private | |
| 19:44:32 | sean-k-mooney | excpet to the tenants listed | |
| 19:46:00 | sean-k-mooney | gmann: if that is not the case then i agree that this should be mutable in the flavor api | |
| 19:46:34 | sean-k-mooney | you cant really gracefully retire a flavor othersize. | |
| 19:47:22 | openstack | Launchpad bug 1361476 in OpenStack Compute (nova) "flavor access create should check public/private first" [Low,Fix released] - Assigned to Sergey Nikitin (snikitin) | |
| 19:47:22 | sean-k-mooney | it looks like it was change as a result of this bug https://bugs.launchpad.net/nova/+bug/1361476 | |
| 19:47:51 | gmann | humm, but will change in is_public on embedded instances effect like make that flavor stale. the reason we do not allow flavor modification on other parameters. | |
| 19:48:14 | sean-k-mooney | my expectation is that if a flaovr is public and i add a tenatn via os-flavor-access then any tenant other then those listed via flavor access would not see it | |
| 19:48:48 | sean-k-mooney | gmann: is public on the embeded instance has no meaning | |
| 19:49:03 | sean-k-mooney | so i dont think its an issue | |
| 19:49:03 | gmann | and keep is_public same ? | |
| 19:49:13 | gmann | listing flavor? | |
| 19:49:17 | sean-k-mooney | yes | |
| 19:49:30 | sean-k-mooney | so my expectation is is_public would still be public/true | |
| 19:49:35 | sean-k-mooney | and flavor list would not list | |
| 19:49:37 | sean-k-mooney | it | |
| 19:49:53 | sean-k-mooney | unless you were in the tenant on the access list or an admin | |
| 19:50:30 | openstack | Launchpad bug 1361476 in OpenStack Compute (nova) "flavor access create should check public/private first" [Low,Fix released] - Assigned to Sergey Nikitin (snikitin) | |
| 19:50:30 | sean-k-mooney | so basicaly i think https://bugs.launchpad.net/nova/+bug/1361476 was invalid | |
| 19:51:05 | gmann | i mean we have is_public in list flavor filters if anyone listing by their instance's flavor is_public flag | |
| 19:51:09 | sean-k-mooney | well actully maybe not | |
| 19:51:49 | sean-k-mooney | gmann: can you say that again | |
| 19:52:45 | sean-k-mooney | looking at the bug i would expect "nova flavor-access-list --flavor 1" to work but i would not expect the flavor to be in "openstack flavor list" unless you were in a tenant with acess or an admin | |
| 19:52:47 | gmann | i mean will is_public change the flavor signature or not? even that does not make any change in real configueation but still a attribute in flavor user facing dict | |
| 19:53:27 | sean-k-mooney | is_public only changes if you can see the flaovr or not | |
| 19:53:48 | sean-k-mooney | so i think that is just metadata about the flaovr | |
| 19:53:51 | sean-k-mooney | not a part of it | |
| 19:54:04 | gmann | yeah. kind of. | |
| 19:54:14 | sean-k-mooney | kind of like the description wich we allow to be udpated | |
| 19:54:15 | gmann | or we just remove this flag. | |
| 19:54:49 | sean-k-mooney | i think the only benift to it is the defualt polciy | |
| 19:55:04 | sean-k-mooney | e.g. should it be visable by default or not | |
| 19:55:26 | sean-k-mooney | but i certenly dont think we should be blocking the use of the flaovr acess api based on it | |
| 19:56:00 | sean-k-mooney | i would be ok with removing it too but im not sure how others would feel | |
| 19:56:35 | sean-k-mooney | e.g. do operators use it frequently. if soo i think it should be kept and mutable. if not remove and just use flavor acess api for this | |
| 19:56:42 | gmann | ok, even list public flavor on list access is not wrong which is why that bug did the change in add access | |
| 19:57:18 | gmann | sorry, need to go for lunch, ttyl | |
| 19:57:27 | sean-k-mooney | no worries | |
| 19:57:36 | sean-k-mooney | im going for food too | |
| 19:59:06 | noonedeadpunk | it was pretty interesting discussion. Like I thought it is a bit more simple than it is | |
| 19:59:43 | sean-k-mooney | well the code is simple to change but it has several other implications obvirously | |
| 20:00:09 | sean-k-mooney | noonedeadpunk: this is why we generally require a spec for api changes as this type of discussion normally happens when we dig into it | |
| 20:00:57 | noonedeadpunk | yeah and it is fair | |
| 20:01:47 | noonedeadpunk | will try to write down it as it seems that some patching is required anyway | |
| 20:36:16 | gmann | yeah, spec can be better idea to discuss if something we miss. sean-k-mooney proposal looks ok to me for now. | |
| 20:50:56 | openstackgerrit | Merged openstack/nova master: Lowercase ironic driver hash ring and ignore case in cache https://review.opendev.org/711680 | |
| 21:00:23 | openstackgerrit | melanie witt proposed openstack/nova stable/train: Lowercase ironic driver hash ring and ignore case in cache https://review.opendev.org/713739 | |
| 21:36:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP gate: Ensure n-cpu is stopped on the subnode during evacuation https://review.opendev.org/713674 | |
| 23:36:56 | alex_xu | dansmith: artom, thanks for the review https://review.opendev.org/#/c/687856/15/nova/compute/manager.py@8346, I reply that, but yes, we tried differnt options, and back and forward many times ourselve, looking for suggestion :) | |
| #openstack-nova - 2020-03-19 | |||
| 00:08:09 | artom | alex_xu, sure, I'll take another look tomorrow | |
| 00:18:47 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-flavor-access policies https://review.opendev.org/713697 | |
| 01:05:18 | openstackgerrit | Merged openstack/nova master: Refine and introduce correct parameters for test_get_guest_config_numa_host_instance_topo_cpu_pinning https://review.opendev.org/713351 | |