Earlier  
Posted Nick Remark
#openstack-nova - 2019-11-22
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!"
15:21:46 mriedem i'd say get started on the spec to get initial feedback on the problem statement and the proposed change
15:22:16 mlycka Right, I just need(ed) to get a feel for the way it currently operates and why it hit a brick wall previously.
15:22:58 mriedem i can't remember all the details about that spec but i think they also wanted it to take a list of servers or something
15:23:06 mriedem anyway, what i've said above is likely much more doable
15:23:44 mlycka Yeah, I think that spec was more about snapshotting/quiescing multi-vm setups in a predictable order.
15:24:10 mlycka Yep, gotcha'. I'll poke around the code for a bit and come up with a spec. Thanks.
15:24:21 mriedem np
15:27:04 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support service_host filtering for os-hypervisor API https://review.opendev.org/695708
15:27:21 mriedem stephenfin: what is neutron-network? https://review.opendev.org/#/c/686812/7/releasenotes/notes/remove-nova-network-c02953ba72a1795d.yaml is that something you're cooking up for nova v4?
15:28:03 stephenfin damn it
15:28:11 stephenfin I'll draft a follow-up once I'm done here
15:32:02 ayoung once we merge Nova Network, we should merge Authentication in to Nova and decommision Keystone
15:37:09 mriedem stephenfin: while you're collecting FUPs https://review.opendev.org/#/c/686810/7/api-ref/source/os-tenant-network.inc@2
15:40:13 mriedem stephenfin: gibi: bauzas: dug a bit too deep here it looks like https://review.opendev.org/#/c/686810/7
15:40:42 bauzas dang
15:40:49 bauzas we broke the world again.
15:41:04 gibi ack
15:41:26 bauzas who pushes it out of the gate ?
15:41:32 bauzas stephenfin: ^
15:41:51 stephenfin we broke something?
15:41:54 stephenfin huh?
15:42:06 bauzas stephenfin: not yet (c)
15:42:23 bauzas but mriedem provided (again) a good comment
15:42:29 bauzas and we don't want the change to merge now
15:42:33 bauzas https://review.opendev.org/#/c/686810/7
15:43:06 mriedem the GETs were not removed
15:43:12 stephenfin ah, I see now
15:43:15 mriedem but you removed them in docs, policy and tests
15:44:27 stephenfin Go me \o/
15:47:55 mriedem if you're going to rebase, might as well fix that release note later in the series,
15:48:00 mriedem and also a question here https://review.opendev.org/#/c/686813/8/nova/cmd/manage.py@a2673
15:49:30 melwitt why do we want to keep the GETs?
15:49:37 mriedem they are proxies for neutron and work
15:49:45 mriedem i mean, they'll work once nova-network is gone
15:50:06 melwitt oh ok. I thought we didn't want to keep proxies
15:50:25 mriedem the GETs are capped at 2.35
15:50:55 mriedem iow, proxies have already been deprecated for a long time
15:50:59 mriedem newton i think
15:52:13 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove '/os-tenant-networks' REST API https://review.opendev.org/686810
15:52:20 mriedem pulled from the gate ^

Earlier   Later