| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-14 | |||
| 23:51:19 | sean-k-mooney | it need 3.29.0 | |
| 23:51:42 | sean-k-mooney | are we allowed to bump it like that in a backport? | |
| 23:54:02 | sean-k-mooney | for what its worth i think its a good thing to backport just dont know what stable policy allows | |
| 23:54:06 | melwitt | oh yeah, we aren't. so I guess I was right originally, that it couldn't be backported | |
| 23:54:34 | melwitt | sigh | |
| 23:55:15 | sean-k-mooney | well with the patch on gerrit if peopel want to use it it should be eaiser for them | |
| 23:56:13 | sean-k-mooney | to do the backport you would have to add the fair lock form oslo to noava | |
| 23:56:32 | sean-k-mooney | and just use that instead | |
| 23:57:04 | melwitt | yeah, I doubt it's worth going that far | |
| 23:57:51 | sean-k-mooney | ya | |
| #openstack-nova - 2021-01-15 | |||
| 03:29:21 | openstackgerrit | Brin Zhang proposed openstack/nova master: Cyborg shelve/unshelve support https://review.opendev.org/c/openstack/nova/+/729563 | |
| 08:04:06 | gibi | dansmith: thanks for finding out reasone of the multistore failure an proposing a fix. nice catch! | |
| 08:17:31 | lyarwood | morning | |
| 08:18:04 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/754700 | |
| 08:18:04 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove MIN_{LIBVIRT,QEMU}_BLOCKDEV https://review.opendev.org/c/openstack/nova/+/754701 | |
| 08:18:05 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove MIN_LIBVIRT_S390X_CPU_COMPARE https://review.opendev.org/c/openstack/nova/+/754704 | |
| 09:11:34 | openstackgerrit | wushiming proposed openstack/os-vif master: Drop lower-constraints job https://review.opendev.org/c/openstack/os-vif/+/770907 | |
| 09:17:59 | nightmare_unreal | Hello , is there a way to force a VM to boot from volume. For e.g. during VM creation i want to enforce that it should be from volume only | |
| 09:19:21 | kashyap | lyarwood: Morning; for the NEXT_ version bump, we also traditionally give a heads-up on the openstack-discuss list -- wanna do that too? (E.g. one of my past emails: http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010907.html) | |
| 09:22:29 | openstackgerrit | wushiming proposed openstack/python-novaclient master: Drop lower-constraints job https://review.opendev.org/c/openstack/python-novaclient/+/770912 | |
| 09:24:43 | lyarwood | kashyap: yup can do | |
| 09:25:14 | kashyap | Thank ya. | |
| 09:35:56 | songwenping_ | sean-k-mooney: Hi, what do you means about the vgpu spec: https://review.opendev.org/c/openstack/nova-specs/+/750116/17#L97, should we use rpc.cast the cyborg-agent to create a new mdev? | |
| 09:37:28 | lyarwood | kashyap: sent | |
| 09:39:43 | kashyap | lyarwood: Just read the mail in the archives; looks fine, thx. | |
| 09:41:59 | lyarwood | cool thanks | |
| 10:20:21 | songwenping_ | gibi: hi, about your comment in line https://review.opendev.org/c/openstack/nova/+/622336/20/nova/api/openstack/compute/remote_consoles.py#186, `if svc.version < |
|
| 10:21:14 | brinzhang0 | gibi: cyborg shelve/unshelve updated alex_xu's concern, pls re-check again, thanks https://review.opendev.org/c/openstack/nova/+/729563 | |
| 10:21:30 | gibi | songwenping_: I would go with http 400 | |
| 10:21:38 | gibi | brinzhang0: ack | |
| 10:22:38 | songwenping_ | gibi: get | |
| 10:23:06 | brinzhang0 | gibi: yes, the same as songwenping_'s concern , IMO 400 is more suitable | |
| 10:24:21 | brinzhang0 | gibi: thanks for check the cyborg shelve/unshelve patch ^^ | |
| 11:29:47 | openstackgerrit | Lee Yarwood proposed openstack/nova master: api: Log os-resetState as an instance action https://review.opendev.org/c/openstack/nova/+/770926 | |
| 11:43:24 | gibi | bauzas: are your concerns answered in https://review.opendev.org/c/openstack/nova/+/729563 ? I'm holding the +W until ack it | |
| 12:36:00 | sean-k-mooney | songwenping__: i was suggesting that gets shoudl not create teh mdev ever. the cyborg agent should create the mdevs for all bound arqs on start up. ideally it would set the binding state to "provisioning" on start up also and we would have anohter state "unknown" that the api would report if the cyborg agent misses its heart beat | |
| 12:37:12 | sean-k-mooney | songwenping__: so on start up nova would see 1 of 3 states, bound if the cyborg agent started first and hadn completed bininding, unknown if the cyborg agent has not heartbeat to the cyborg conductor yet | |
| 12:37:36 | sean-k-mooney | or provisioning if the agent is in the process of creating the mdev | |
| 12:38:32 | sean-k-mooney | if cyborg was to send the same bining complete event when it change teh status form provisioning to bound as it does during normal arq binding | |
| 12:38:45 | sean-k-mooney | the process in nova awould be the same | |
| 12:39:34 | sean-k-mooney | e.g. set up event handeler, check if its already bound if not wait for binding complete event, if it si bound cancel the even waiter and proceed with boot | |
| 12:40:55 | sean-k-mooney | gibi: bauzas does that sound like a resonable approch to ye instead of have get arq sometimes do an rpc call to the cybrog agent to create mdevs | |
| 12:41:37 | bauzas | gibi: will look at https://review.opendev.org/c/openstack/nova/+/729563 | |
| 12:42:28 | gibi | bauzas: thanks | |
| 12:42:57 | bauzas | and for the vGPU support in Cyborg, I'll also look at the new revision today | |
| 12:43:41 | gibi | sean-k-mooney: do we have this event handling at nova compute startup for neutron ports too? | |
| 12:44:48 | sean-k-mooney | gibi: we do not need to rebinding them in the neutron case just replug them. | |
| 12:45:18 | sean-k-mooney | in the neutorn case os-vif is the thing that attaches the ports to the network backend in general | |
| 12:45:37 | sean-k-mooney | which si the equivalent of creating the mdev | |
| 12:45:45 | gibi | sean-k-mooney: I see | |
| 12:47:47 | sean-k-mooney | i just find it unsetaling that we would considre change a get form a simple db lookup into an rpc call | |
| 12:48:25 | gibi | sean-k-mooney: so at compute startup nova gets the binding state from cyborg, if it is unknow or provisioning then keep the guest power state off but set up an event waiter. If the arq state is "OK" then nova would start the guest during compute startup. | |
| 12:48:45 | sean-k-mooney | gibi: not quite | |
| 12:48:50 | gibi | correct me please | |
| 12:49:30 | sean-k-mooney | i was thinking we would always set up the waiter and early out if it was bound like we do for normal spwan | |
| 12:50:02 | gibi | can nova we loose an event during the compute reboot? | |
| 12:50:29 | gibi | if yes then that guest would be stuck waiting of the event that was sent by cyborg but lost in the comptue restart | |
| 12:51:03 | gibi | if the event is never lost then I'm OK to wait for the event | |
| 12:51:05 | sean-k-mooney | the event would hit the api and then be enqued to the compute node topic queue | |
| 12:51:15 | sean-k-mooney | so i dont think it would be lost | |
| 12:51:15 | gibi | sean-k-mooney: cool | |
| 12:51:20 | gibi | that seem OK | |
| 12:51:34 | gibi | hm | |
| 12:52:12 | gibi | so in this case the sending the event is triggered by cyborg agent restart, in any other case sending the event is triggered by a nova bind request | |
| 12:52:39 | sean-k-mooney | yes | |
| 12:53:09 | gibi | so there are extra cases to handle. 1) a single cyborg agent restart will send events and if the compute service was not restarted then these events needs to be consumed but ignored | |
| 12:53:14 | sean-k-mooney | we could just call bind if we wanted too and not require teh cyborg agent to auto create them but i think the auto create would be more efficent | |
| 12:54:00 | sean-k-mooney | gibi: we have unexpeted event handeling in nova already | |
| 12:54:05 | gibi | cool | |
| 12:54:19 | sean-k-mooney | if we dont have a waiter when we deque it we just log it and discard | |
| 12:54:28 | gibi | that seems OK too then | |
| 12:54:34 | sean-k-mooney | which si ok because we will check the state when we get to that part of the code | |
| 12:55:44 | sean-k-mooney | basically im just suggesting using the exact saem event system we use of inital sapwn after where we start the binidng in the conductor then wait for it with an early out in the compute | |
| 12:56:03 | gibi | OK, I don't have a #2 actually :) | |
| 12:56:06 | sean-k-mooney | but in this case the cyborg agent would start the bind on start up | |
| 12:56:25 | gibi | sean-k-mooney: so far what you suggest feels OK to me | |
| 12:57:25 | sean-k-mooney | ill find the time stamp for this and add it to the reveiw | |
| 12:57:31 | gibi | cool | |
| 12:57:32 | gibi | thanks | |
| 12:57:55 | sean-k-mooney | bauzas: if you have time to read scool back and find anything concering with that please chime in | |
| 13:26:56 | bauzas | sean-k-mooney: looking | |
| 13:33:44 | bauzas | sean-k-mooney: are you talking about creating the mdevs in sysfs or binding them to the instance by modifying the XML ? | |
| 13:35:54 | sean-k-mooney | bauzas: sysfs | |
| 13:36:01 | bauzas | ack | |
| 13:36:16 | bauzas | if so, I agree, Cyborg should create them | |
| 13:36:22 | sean-k-mooney | specifically cyborg creating them | |
| 13:36:28 | bauzas | (the agent) | |
| 13:36:43 | sean-k-mooney | right but it shoudl do it automatically rather then as a result of a GET ot ARQ show | |
| 13:37:23 | sean-k-mooney | well GET /ARQ/<uuid> | |
| 13:55:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP/DNM libvirt: Start emitting DeviceRemovedEvent and DeviceRemovalFailedEvent events https://review.opendev.org/c/openstack/nova/+/749929 | |
| 13:55:35 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM try to replace retry with libvirt event in detach https://review.opendev.org/c/openstack/nova/+/770246 | |
| 13:59:34 | bauzas | sean-k-mooney: yeah, provisioning them directly | |
| 14:00:00 | bauzas | once the operator modifies the config | |
| 14:00:22 | sean-k-mooney | what config? | |
| 14:00:40 | bauzas | their own config for telling which vgpu type for each pGPU | |
| 14:00:45 | sean-k-mooney | we are talking about recreating them after a host reboot | |
| 14:01:14 | sean-k-mooney | the cyborg spec currently say after a host reboot when we reboot the instance that we will do a arq show | |
| 14:01:25 | bauzas | I haven't seen it | |
| 14:01:26 | sean-k-mooney | and that show will do an rpc to the agent to create the mdev | |
| 14:01:28 | bauzas | if so, -1 for me | |