| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-18 | |||
| 19:09:58 | lyarwood | not c-vol | |
| 19:10:00 | prometheanfire | looks like alembic is still failing for nova / neutron https://review.opendev.org/708706 | |
| 19:10:05 | sean-k-mooney | ah ok | |
| 19:10:29 | sean-k-mooney | the ceph thing was confusing me | |
| 19:10:51 | sean-k-mooney | and ya that kind of makes sense | |
| 19:11:12 | sean-k-mooney | so we not only need to stop the compute agent but the vms on the sub node too | |
| 19:11:37 | sean-k-mooney | which i guess makes sense | |
| 19:12:00 | sean-k-mooney | so we should stop the compute agent. then use libvirt to stop all the vms on the subnode | |
| 19:12:06 | sean-k-mooney | then do an evacuate | |
| 19:16:14 | lyarwood | sean-k-mooney: kk, I'll give that a go. | |
| 19:16:58 | lyarwood | sean-k-mooney: here's a thought, shouldn't all devstack@* services be stopped on the subnode? | |
| 19:17:25 | sean-k-mooney | i was consider doing a power off on the subnode | |
| 19:17:31 | sean-k-mooney | but i think we need logs from it | |
| 19:18:02 | sean-k-mooney | but yes you could do "sudo systemctl stop devstack@*" | |
| 19:18:29 | sean-k-mooney | that would be totally valid to do provide we dont install cpeh there | |
| 19:19:00 | sean-k-mooney | if we are installing ceph in the devstack slice then that woudl be an issue | |
| 19:22:20 | noonedeadpunk | hi! is there any reason (like security or other) why flavor transition from public to private or vice versa is not supported? | |
| 19:22:47 | sean-k-mooney | noonedeadpunk: private flavors was a half impleneted feature that is not commonly used | |
| 19:23:18 | sean-k-mooney | noonedeadpunk: so support was not added. | |
| 19:23:25 | noonedeadpunk | oh really? Like I was using it pretty much in several clouds | |
| 19:23:26 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP gate: Ensure n-cpu is stopped on the subnode during evacuation https://review.opendev.org/713674 | |
| 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 | openstackgerrit | melanie witt proposed openstack/nova master: DNM: try to get some debug info for bug 1844929 https://review.opendev.org/701478 | |
| 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: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 | sean-k-mooney | it looks like it was change as a result of this bug https://bugs.launchpad.net/nova/+bug/1361476 | |
| 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: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 | gmann | and keep is_public same ? | |
| 19:49:03 | sean-k-mooney | so i dont think its an issue | |
| 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 | sean-k-mooney | so basicaly i think https://bugs.launchpad.net/nova/+bug/1361476 was invalid | |
| 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: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 | |