| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-22 | |||
| 12:11:03 | sean-k-mooney | the might unitll we fix the standalone mode but in a normal tipleo deployment it set the hostname to match the value it sets in the host config option | |
| 12:12:01 | sean-k-mooney | in standalone mode the host os is installed manually and therfor cloud-init does not run and that step is not done | |
| 12:12:55 | gibi | as a side track I filed bug as nova compute fails if the CONF.host is changed after initial deployment https://bugs.launchpad.net/nova/+bug/1853587 | |
| 12:12:55 | openstack | Launchpad bug 1853587 in OpenStack Compute (nova) "nova compute fails to update inventory in placement after changing [DEFAULT]/host" [Undecided,New] | |
| 12:14:14 | sean-k-mooney | ya that is basically the same issue not entirely but close enough | |
| 12:16:38 | sean-k-mooney | gibi: ok so we use the host option to create teh compute service recored but the hypervior_hostname for the placement name | |
| 12:17:04 | sean-k-mooney | so changing CONF.host after the fact causes us to creat a new service record and uuid | |
| 12:17:12 | gibi | sean-k-mooney: yepp, which is logical if we have to support more than one hypervisors per service | |
| 12:17:32 | sean-k-mooney | but then when we try to create the RP we get a colission on the hyperviour_hostname right | |
| 12:17:39 | gibi | sean-k-mooney: right | |
| 12:17:59 | gibi | sean-k-mooney: I guess if you need to change CONF.host then first have to cleanup the old service and placement | |
| 12:18:45 | sean-k-mooney | that or if we dont find the service record by host check if its theyer by hypervior hostname and then upstat the host field? | |
| 12:19:01 | sean-k-mooney | not sure that would be right in all cases however | |
| 12:19:25 | sean-k-mooney | draning deleting and recreating seams safer | |
| 12:20:46 | sean-k-mooney | funnily enough we have a customer that want to be able to do a backup and restor of the compute node and potentially chang ethe hostname since there hostnames are determine by the location of the server and they may need to restore to a different host | |
| 12:21:23 | gibi | that sounds fun | |
| 12:21:26 | sean-k-mooney | if they were not still running a pre placement version of openstack they would hit this issue | |
| 12:22:16 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Take an instance.uuid lock when rebooting https://review.opendev.org/673463 | |
| 12:27:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during a rescue https://review.opendev.org/270287 | |
| 12:27:37 | sean-k-mooney | gibi: did i mention i also traced how neuton learns what hostname to use in the frist place | |
| 12:28:09 | gibi | sean-k-mooney: I think you did and I also looked at the code with the help of lajoskaton this morning | |
| 12:28:26 | sean-k-mooney | its via the agent report | |
| 12:28:39 | openstackgerrit | Merged openstack/nova master: Specify what RPs _ensure_resource_provider collects https://review.opendev.org/695429 | |
| 12:28:45 | openstackgerrit | Merged openstack/nova master: nova-net: Add TODOs for remaining nova-network functional tests https://review.opendev.org/684345 | |
| 12:29:01 | sean-k-mooney | so to use the actual hostname we would have to extend the report with a hypervior hostname field | |
| 12:29:21 | sean-k-mooney | then the neutron server could use that if its present | |
| 12:29:54 | gibi | sean-k-mooney: exaclty, which is an RPC change which might not be backportable | |
| 12:30:06 | gibi | hence my reply asking neutron folks about it | |
| 12:30:06 | sean-k-mooney | its not an object change | |
| 12:30:21 | sean-k-mooney | its an unversioned dict of strings field | |
| 12:30:37 | sean-k-mooney | at least it used to be | |
| 12:30:52 | gibi | sean-k-mooney: neutron server still need to have a way to handle old RPC reports from not upgraded agents | |
| 12:31:46 | sean-k-mooney | ya which could be to either first try to look up in placmene by its existing host value. | |
| 12:32:10 | sean-k-mooney | and if it fails then fallback to the full hyperviour list and cache the result | |
| 12:32:40 | sean-k-mooney | normally the CONF.host and hypervior_host will be the same in the libvirt case | |
| 12:39:37 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: Use admin neutron client to query ports for binding https://review.opendev.org/694665 | |
| 12:40:30 | gibi | elod: ^^ fixed your comment | |
| 12:40:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: Use admin neutron client to see if instance has qos ports https://review.opendev.org/694668 | |
| 12:41:04 | elod | gibi: thx, looking | |
| 12:43:03 | gibi | oooo ma csovet is fognak ma vagni | |
| 12:43:11 | gibi | az nagyon meno lesz | |
| 12:58:02 | gibi | wrong window obviously | |
| 13:44:27 | openstackgerrit | Merged openstack/nova master: Remove 'os-security-group-default-rules' REST API https://review.opendev.org/686807 | |
| 13:44:33 | openstackgerrit | Merged openstack/nova master: nova-net: Remove unused '*_default_rules' security group DB APIs https://review.opendev.org/686808 | |
| 13:44:40 | openstackgerrit | Merged openstack/nova master: Remove (most) '/os-networks' REST APIs https://review.opendev.org/686809 | |
| 14:10:31 | openstackgerrit | Merged openstack/nova stable/train: Add functional recreate test for bug 1852610 https://review.opendev.org/694544 | |
| 14:10:31 | openstack | bug 1852610 in OpenStack Compute (nova) train "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Undecided,In progress] https://launchpad.net/bugs/1852610 - Assigned to Matt Riedemann (mriedem) | |
| 14:35:36 | mlycka | Hi again, quick question, is there no 'quiesced' state for VMs? | |
| 14:42:08 | johnthetubaguy | mlycka: I don't think there is, but there is a state of snapshotting, or something like that, during which time it might be quiesced | |
| 14:44:03 | mriedem | i think that's when creating a snapshot of an active volume-backed instance | |
| 14:44:08 | mriedem | and only if the driver and image support it | |
| 14:44:16 | mriedem | i.e. qemu guest agent | |
| 14:44:37 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3213 | |
| 14:44:45 | mlycka | Right right...I'm just looking through an older patch which added a new state as part of exposing quiescing/unquiescing in the API. I'm guessing that would still have to be done for that functionality to be implemented. | |
| 14:46:53 | mriedem | i don't see that we even set the task_state on the instance while creating a volume-backed snapshot, which seems bad | |
| 14:47:05 | mriedem | means you could like migrate the server while creating the snapshot | |
| 14:47:29 | mriedem | https://github.com/openstack/nova/blob/991d675675c1c6bb87a2b9d19327e2b4473f6c0b/nova/compute/task_states.py#L34 | |
| 14:48:56 | mriedem | we uh don't even have a different server status during a snapshot https://docs.openstack.org/api-guide/compute/server_concepts.html | |
| 14:49:44 | mriedem | anyway, that'd be an extremely latent issue | |
| 14:50:24 | openstackgerrit | Merged openstack/nova stable/train: Add functional recreate revert resize test for bug 1852610 https://review.opendev.org/694545 | |
| 14:50:24 | openstack | bug 1852610 in OpenStack Compute (nova) train "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Undecided,In progress] https://launchpad.net/bugs/1852610 - Assigned to Matt Riedemann (mriedem) | |
| 14:51:15 | mlycka | mriedem: How do you mean latent? | |
| 14:56:41 | mriedem | meaning if it's a bug, it's always been there | |
| 14:57:02 | mriedem | i just posted some of this to the ML since i think i come across this stuff like every year or so and wonder the same things | |
| 14:57:29 | mlycka | Sorry, ML? | |
| 14:58:02 | mriedem | mailing list | |
| 14:58:11 | mlycka | Right, thanks | |
| 14:58:16 | mriedem | http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011073.html | |
| 14:58:56 | melwitt | sean-k-mooney: ah, thanks for the context | |
| 14:59:52 | stephenfin | anyone want to hit this for me so I can keep the remove-nova-network train moving? https://review.opendev.org/#/c/686811/7 | |
| 15:01:41 | mriedem | stephenfin: looking, | |
| 15:01:51 | mriedem | stephenfin: you want to rebase your remove os-consoles change? then i can re-approve | |
| 15:08:33 | mriedem | stephenfin: question https://review.opendev.org/#/c/686811/7/nova/tests/functional/wsgi/test_interfaces.py@a44 | |
| 15:10:25 | mlycka | mriedem: Shouldn't quiescing have a state separate from snapshot though? | |
| 15:10:27 | jroll | efried: dansmith: I'm back from an offsite thing and will catch up on vtpm discussion today, thanks for the pings | |
| 15:11:29 | mriedem | stephenfin: nevermind, i answered my own question | |
| 15:12:12 | mriedem | mlycka: if anything i think it would be a task_state as part of an overall snapshot "status" | |
| 15:12:31 | mriedem | so if we had a SNAPSHOTTING status in the API, the task_state would be "quiescing" | |
| 15:12:51 | mriedem | note that image-backed snapshot has 4 separate task_states | |
| 15:15:50 | mlycka | mriedem: I'm sort of coming from an angle here and I'm still finding my feet with the nova state machine, so bear with me here: I'm looking at introducing the (un)quiesce operations into nova API for use by other entities (Cinder in my case). Would that not point to a quiesce state outside of the existing snapshot process? | |
| 15:17:08 | mriedem | quiesce isn't a terminal state of a server though | |
| 15:17:27 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support service_host filtering for os-hypervisor API https://review.opendev.org/695708 | |
| 15:17:39 | mriedem | so you want to do something initiated in cinder and if the volume is attached to a server you want to call nova's rest api and tell nova to quiesce the instance, right? | |
| 15:17:40 | stephenfin | mriedem: in a meeting but I'll rebase that soon as I'm done, yup | |
| 15:17:41 | stephenfin | and thanks | |
| 15:17:55 | mlycka | mriedem: Correct. | |
| 15:18:11 | mriedem | mlycka: ok i think the api for that would be the os-server-external-events api https://docs.openstack.org/api-ref/compute/#create-external-events-os-server-external-events | |
| 15:18:29 | mriedem | which cinder already uses when extending the size of a volume attached to a server | |
| 15:19:03 | mriedem | it's still a compute api microversion change to change the schema of that api, but all of the plumbing already exists in the api layer, you just would need to implement the calls when the event is 'quiesce' or whatever | |
| 15:19:37 | mlycka | Goodness me, I didn't even realize this existed | |
| 15:19:58 | mriedem | i'm assuming you've seen the old huawei spec that was trying to expose quiesce/unquiesce out of the API for normal users? | |
| 15:20:03 | mriedem | because that didn't get traction | |
| 15:20:22 | mlycka | Yep, tried asking around earlier precisely for that reason but didn't get a respond | |
| 15:20:28 | mriedem | working it into os-server-external-events as part of a larger orchestrated operation initiated in cinder is probably the way to go | |
| 15:20:29 | mlycka | *response | |
| 15:20:49 | mriedem | so just model it on the volume-extended event | |
| 15:21:03 | mlycka | Well thank you kindly, I'll look into it | |
| 15:21:25 | mriedem | mlycka: it will require a spec https://specs.openstack.org/openstack/nova-specs/readme.html | |
| 15:21:32 | mlycka | I was just going to say | |
| 15:21:35 | mriedem | so before implementing a ton of code and then saying "here it is!" | |